In C, {0} is the universal zero initializer equivalent to C++'s {} (the latter being invalid in C). It is necessary to use whenever you want a zero-initialized object of a complete but conceptually-opaque or implementation-defined type. The classic example in the C standard library is mbstate_t: mbstate_t state = { 0 }; /* correctly zero-initialized */ versus the common but nonportable: mbstate_t state; memset(&state, 0, sizeof state); In this case, gcc -Wbraces (which is included in -Wall) actively discourages the programmer from writing the correct form of the code by throwing ugly warnings. Note that if you want to eliminate warnings and write portable code, the *only* way to zero-initialize an object like this is: static const mbstate_t zero_state; mbstate_t state = zero_state; (i.e. creating an extra object of static storage duration to be implicitly zero initialized). The same reasoning applies to any structures provided by third-party libraries which must be allocated by the calling application and zero-initialized, but whose definitions are intended to be considered as opaque. To fix the issue, GCC should simply special-case {0} as always-valid and suppress warnings for it, while leaving in effect all other behaviors of -Wbraces.
Where did you get your compiler? -Wbraces is not a valid option in the original GCC. http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options
Sorry, I wrote the bug report without GCC in front of me. The correct name for the warning option is -Wmissing-braces.
I can't get reproduce this. Could you provide a small reproducible testcase? Plus the info asked here: http://gcc.gnu.org/bugs/#need
Created attachment 27242 [details] minimal test case Glibc's mbstate_t is defined as a struct whose first element is an int (not another struct/union/array), so the warning does not happen there. I'm uploading a minimal example case with an explicitly defined struct.
It seems to me you are right. However, I cannot see how to check for ={0} at the point of the warning. Joseph, any ideas? This part of the C FE is ancient.
On Wed, 25 Apr 2012, manu at gcc dot gnu.org wrote: > It seems to me you are right. However, I cannot see how to check for ={0} at > the point of the warning. > > Joseph, any ideas? This part of the C FE is ancient. In general I think Jakub is more expert on the code for handling initializers than I am.
(In reply to comment #6) > On Wed, 25 Apr 2012, manu at gcc dot gnu.org wrote: > > > It seems to me you are right. However, I cannot see how to check for ={0} at > > the point of the warning. > > > > Joseph, any ideas? This part of the C FE is ancient. > > In general I think Jakub is more expert on the code for handling > initializers than I am. OK, but do you agree that the warning should be silenced always for ={0}? Jakub, do you have any pointers for this? At the point of the warning "value" is null, so I am not sure how to check for ={0}. There is a boolean zeroinit later, bool constructor_zeroinit = (VEC_length (constructor_elt, constructor_elements) == 1 && integer_zerop (VEC_index (constructor_elt, constructor_elements, 0)->value)); but this vector is not initialized in this case.
On Thu, 26 Apr 2012, manu at gcc dot gnu.org wrote: > OK, but do you agree that the warning should be silenced always for ={0}? Yes, I think that makes sense.
Maybe related PR25137 Confirmed by Joseph. Any help welcome!
I'd like to add that this is a definite problem when moving a codebase from a different compiler to gcc. I'm having to individually fix up ={0} cases to match the content of the structure being initialised, which is a PITA, and I think against the C standard which I believe allows ={0} as a default zero initialiser for structs of whatever content. Therefore, is there any progress on this bug?
(In reply to JamesH from comment #10) > > Therefore, is there any progress on this bug? I wouldn't expect any soon, unless new developers join GCC development and decide to work on the C FE. Any takers?
Author: law Date: Thu Jun 5 19:36:03 2014 New Revision: 211289 URL: http://gcc.gnu.org/viewcvs?rev=211289&root=gcc&view=rev Log: 2014-06-05 S. Gilles <sgilles@terpmail.umd.edu> PR c/53119 * c-typeck.c (push_init_level, process_init_element, pop_init_level): Correct check for zero initialization, move missing brace warning to respect zero initialization. PR c/53119 * gcc.dg/pr53119.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr53119.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
This is related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36750 Can someone update the see also field? Also, can this change be applied to c++ as well? Initializing a c struct in c++ code exhibits the same behavior.
In C++, the correct zero initializer is {}, not {0}. I'm not an expert in C++ but I think {0} in C++ might even be a constraint violation unless the brace level happens to match.
Should be fixed.
Created attachment 33228 [details] backported fix for gcc 4.7.4 backported fix for gcc 4.7.4 attached. was tested building about 500 packages, no regressions have been detected.
I'm sorry, GCC 4.7 branch is already closed.
Created attachment 33229 [details] backported fix for gcc 4.8.3 oh, is that so? that's unfortunate, as gcc > 4.7 requires a C++ compiler to bootstrap a C compiler. either way, attaching a backport to gcc 4.8.3. unlike the previous backport it wasn't heavily tested, but it seemed to do the right thing in some simple testcases; and there was only one minor change needed to get the upstream patch to apply (different argument count for init_warning()).
Has this been applied yet? (If yes, in which version of gcc?) Seems to be a popular problem, if it's this: http://stackoverflow.com/questions/13746033/how-to-repair-warning-missing-braces-around-initializer
Sorry, the patch hasn't been applied to 4.9 nor 4.8 branch yet, and I don't think it should be backported as-is, because just today I found out that the patch contains a bug; see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64709
Same bug in clang: http://llvm.org/bugs/show_bug.cgi?id=21689 Related bug in POSIX: http://austingroupbugs.net/view.php?id=918 And I think this bug should be fixed even in C++, just because we should have some uniform way to initialize addrinfo and mbstate_t in both C and C++ :) (And gcc 4.9.2 emits warning for C++ but not for C)
The warning is probably correct for C++ because C++ has "{}" as its universal zero initializer, and "{0}" may not (unsure about this; I'm not a C++ expert) even be valid as an initializer for some C++ types. Comments from others more experienced in C++ would be welcome.
Please remove {0} warning at least in cases where {0} is obviously OK (such as addrinfo)
(In reply to Marek Polacek from comment #20) > Sorry, the patch hasn't been applied to 4.9 nor 4.8 branch yet, and I don't > think it should be backported as-is, because just today I found out that the > patch contains a bug; see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64709 Now that PR64709 is fixed, could you please backport both to 4.9 (and possibly 4.8)?
On the same subject, I've reported a new bug: PR 80454.
Does the issue already fixed? Waynem Ccollough https://amsterdamdiary.com/
(In reply to Waynem Ccollough from comment #26) > Does the issue already fixed? For the simplest cases, it is. But complex cases still trigger a warning, see e.g. PR 80454.