bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gold/23411] Different behavior when linking common symbol staticall


From: zenith432 at users dot sourceforge.net
Subject: [Bug gold/23411] Different behavior when linking common symbol statically or to shared object
Date: Sat, 14 Jul 2018 11:16:15 +0000

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]