I asked: > Can this have serious effects (like overlapped or split objects), > or is .size used only for e.g. debugging?
It seems that .size is used for shared libraries compiled without -fPIC: linking the same code statically or with -fPIC fixes the wrong behavior, and -finhibit-size-directive causes linking errors about zero-sized objects. I don't use -fPIC here because it makes code 1.6 times slower. I found that the .size bug has been reported in January 2006: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25805 Comments seem to indicate that it has been fixed for 4.1 and 4.2, but I can see the wrong behavior in both gcc-4.1.0-0.20051206r108118 and gcc-4.2.0-0.20060806r115974. If it's indeed fixed, in which versions? * * * Now I have a problem in my program which uses lots of statically allocated objects with a fixed header and variable sized payload, and some inline functions which operate on objects of varying size. Namely, using flexible array members doesn't work with shared libraries because of the .size bug, and using explicitly sized arrays relies on illegal type punning which breaks in 4.2.0 (even casting a pointer to struct to a pointer to a separately defined struct with identical contents may cause the compiler to think that they can't alias each other and generate subtly wrong code in very rare cases). Workarounds I can see: - Keep explicitly sized arrays, use -fno-strict-aliasing to make it working in the presence of type punning. - Keep explicitly sized arrays, don't inline certain functions (I suppose only a single function is affected), hoping that gcc will not optimize too aggressively. - Use flexible array members, give up shared libraries until gcc is fixed. Any other ideas? -- __("< Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/
