On Thu, Nov 1, 2012 at 1:04 PM, Gisle Vanem gvanem@broadpark.no wrote:
These gcc extensions:
Hi, Gisle!
I'm happy to open another ticket for these, but have you tried using the bugtracker yourself? Is there some UI issue or something that prevents you from opening tickets? If so I'd be glad to try to help work around it, but if not it's really more convenient to have bugtracker tickets to discuss this stuff.
As for the patch, I don't think it's a good idea as-is, for two reasons: * First, the syntax there is *NOT* a GCC extension; it's a standard C99 feature. * Second, the workaround is error-prone. If the fields in the structure are ever designated in an order that doesn't match their declaration order in the structure definition, we'll get a situation where C99-compliant compilers generate the code as intended, but where non-C99-compliant compilers fail, or worse-- generate different code. To be concrete, consider this example:
#include <stdio.h>
struct X { const char *important; const char *actor; const char *victim; };
#if I_HAVE_C99 #define STRUCT_INIT(member,val) member = val #else #define STRUCT_INIT(member,val) val #endif
int main(int argc, char **argv) { struct X y = { STRUCT_INIT(.actor, "vendors"), STRUCT_INIT(.victim, "programmers"), STRUCT_INIT(.important, "Standards") }; printf("%s are important.\n" "When %s support them, that makes life easier for %s.\n", y.important, y.actor, y.victim); return 0; }
So I think the better fix there is probably to verify that the designated initializers are indeed given in the structure declaration order, and then to simply replace them with comments. It's not as good as it would be if we could rely on having a C99 compiler (in 2012), but it's better that risking our code behaving differently on C99 and non-C99 compilers.
yrs,