https://sourceware.org/bugzilla/show_bug.cgi?id=23411
--- Comment #4 from zenith432 at users dot sourceforge.net --- There's an ambiguity in ANSI C about this. From C11 Section 6.9.2 External object definitions 1 If the declaration of an identifier for an object has file scope and an initializer, the declaration is an external definition for the identifier. 2 A declaration of an identifier for an object that has file scope without an initializer, and without a storage-class specifier or with the storage-class specifier static, constitutes a tentative definition. If a translation unit contains one or more tentative definitions for an identifier, and the translation unit contains no external definition for that identifier, then the behavior is exactly as if the translation unit contains a file scope declaration of that identifier, with the composite type as of the end of the translation unit, with an initializer equal to 0. And then there's Annex J (Informative) Portability issues J.5.11 Multiple external definitions 1 There may be more than one external definition for the identifier of an object, with or without the explicit use of the keyword extern; if the definitions disagree, or more than one is initialized, the behavior is undefined (6.9.2). So the normative 6.9.2 decrees things to be the way described in Comment 2, but then J.5.11 which is only informative and is about portability issues talks about "definitions disagree, or more than one is initialized" - but according to 6.9.2 they're always initialized. So when they wrote J.5.11 they still had in mind the concept of a tentative definition which is uninitialized. You could argue there's no contradiction, but there's no reason to include the phrase "or more than one is initialized" unless the concept of tentative definition still has any impact. Anyways, the choice of whether to use ANSI C or GNU extensions is given to the compiler - what business does the linker have enforcing ANSI C after a choice was made during compile-time to use extensions? There are no ld options to choose whether to enforce ANSI C or not. The linker is not even restricted to C. Or C++ (which has ODR). Fortran has common blocks. ld supports Fortran, doesn't it? -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
