On 12/04/15 17:23, Paolo Bonzini wrote: > > > On 04/12/2015 11:39, Laszlo Ersek wrote: >> (4) Linking those two files into a complete program is a violation of >> "6.7 External definitions": >> >> [...] If an identifier declared with external linkage is used in an >> expression (other than as part of the operand of a *sizeof* >> operator), somewhere in the entire program there shall be exactly >> one external definition for the identifier [...] >> >> Again, how does the argument go? >> >> - In each file we have exactly one tentative definition, and no >> declaration that would be, in its own right, an external definition. >> Based on (2), the files must behave exactly as-if there was one >> external *definition* for "x" in each. >> >> - Argument (3) explains why "x" has external *linkage*. >> >> - Argument (4) applies to "x" because "x" has external linkage, and is >> used in a non-sizeof expression. And the requirement set forth in (4) >> is broken by the program because the program is required to behave >> exactly as if "x" had two external definitions. >> >> In practical terms: >> >> - If you compile the first version of the program (without any special >> options), it links together successfully: >> >> $ gcc -std=c89 -pedantic -Wall -Wextra -o f f1.c f2.c >> >> - If you compile the second (equivalent) version of the program, >> linkage fails: >> >> $ gcc -std=c89 -pedantic -Wall -Wextra -o f-b f1-b.c f2-b.c >> >> /tmp/cc8Isbn8.o:(.bss+0x0): multiple definition of `x' >> /tmp/cciQUlDz.o:(.bss+0x0): first defined here >> collect2: error: ld returned 1 exit status >> >> - The gcc bug is that linking the first version *too* should fail, >> without any particular options. > > That's true, but it would break existing code that declares variables in > headers without "extern".
I agree. After I posted the email I pondered what it would take to fix this in gcc. It would be impossible. :) > That's why Visual Studio does the same. Looks plausible. Thanks! Laszlo > > Paolo > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
