This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] sysdeps/ieee754: prevent maybe-uninitialized errors
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Martin Jansa <martin dot jansa at gmail dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 19 Sep 2018 13:22:56 +0000
- Subject: Re: [PATCH 1/2] sysdeps/ieee754: prevent maybe-uninitialized errors
- References: <20180919100825.22999-1-Martin.Jansa@gmail.com>
On Wed, 19 Sep 2018, Martin Jansa wrote:
> * with -O included in CFLAGS it fails to build with:
This is bug 19444, so [BZ #19444] in ChangeLog entries for it. (If your
patch only fixes some of the issues building with -O, your commit message
needs to make it clear, so that it's obvious whether the bug should be
resolved as FIXED with target milestone set to the first mainline release
with the fix immediately after commit. But the bug number should be given
even for changes only fixing part of a bug - they just need to make clear
whether they are complete or partial fixes.)
> + default: temp = 0; // just to prevent error: 'temp' may be used uninitialized in this function [-Werror=maybe-uninitialized]
We don't use // comments in glibc code. We also don't add initializers /
assignments that might generate code just to silence warnings; if the code
cannot be written in a way that makes it clear to the compiler what is /
is not uninitialized, without resulting in extra generated code, we use
the DIAG_* macros from libc-diag.h, with appropriate comments in every
case explaining why in fact the warning is a false positive, to silence
the warnings locally.
Unfortunately <https://sourceware.org/glibc/wiki/Style_and_Conventions>
doesn't mention either of these conventions, so there is clearly scope for
us to improve our documentation on contributing to glibc.
--
Joseph S. Myers
joseph@codesourcery.com