This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 10/28/2016 02:10 PM, Paul Eggert wrote:
And I would echo that markup indicating that the initializer is to work around a GCC false positive is something I wish we had strictly enforced within GCC itself when it was made Wuninitialized clean.On 10/28/2016 01:12 AM, Arnd Bergmann wrote:I found that most often when gcc is confused about whether a variable is uninitialized or not, the source code tends to be confusing to a human reader as well and rewriting it differently results in better readability and better object code while avoiding the warning.I'm afraid my experience has not been so good. Maybe 1/3 of the time rewriting is better, but otherwise rewriting doesn't help or even confuses the code. When that happens with -Wmaybe-uninitialized, in Emacs we typically use C declarations like this: ptrdiff_t offset2 UNINIT; /* The UNINIT works around GCC bug 78081. */
GCC has made significant strides in its jump threading and predicate analysis to significantly such false positives and many of these initializers could probably be removed at this point.
But I would caution against blindly using 0 as an initializer. Each case has to be examined to determine what a safe value would be. Often 0 is appropriate, but there are certainly cases where it is not the safe initializer to use.where UNINIT is defined something like this: #ifdef GCC_LINT # define UNINIT = {0,} #else # define UNINIT /* empty */ #endif and configuring with --enable-gcc-warnings compiles with something like 'gcc -Wall -Werror -DGCC_LINT'.\
Jeff
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |