4

0.c

int i = 5;

int main(){
 return i;
}

1.c

int i;

Above compiles fine with gcc 0.c 1.c without any link errors about multiple definitions. The reason is i gets generated as common blocks (-fcommon which is the default behaviour in gcc). The proper way to do this is using the extern keyword which is missing here.

I have been searching online to see if this is undefined behaviour or not, some post say it is, some say it isn't and it's very confusing:

It is UB

Is having multiple tentative definitions in separate files undefined behaviour?

Why can I define a variable twice in C?

How do I use extern to share variables between source files?

http://port70.net/~nsz/c/c11/n1570.html#J.2

An identifier with external linkage is used, but in the program there does not exist exactly one external definition for the identifier, or the identifier is not used and there exist multiple external definitions for the identifier (6.9).

It is NOT UB

Global variables and the .data section

Defining an extern variable in multiple files in C

Does C have One Definition Rule like C++?

Look for -fno-common: https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/Code-Gen-Options.html

So which one is it? is using -fcommon one of the few places where having multiple definition is allowed and the compiler sorts it out for you? or it is still UB?

Dan
  • 2,694
  • 1
  • 6
  • 19
  • 2
    This is undefined as per standard, but implementation defined on gcc. It is not the only example where something which is undefined "works" due to an extension. – SergeyA May 18 '21 at 13:32
  • 2
    The answer https://stackoverflow.com/questions/67270121/why-can-i-define-a-variable-twice-in-c explains: `.... If a program disobeys this rule, the C standard does not define the behavior (C 2018 4 2). Instead, we let the compiler and the linker define the behavior.` and the whole paragraph. – KamilCuk May 18 '21 at 13:33
  • Try recompiling with `gcc 0.c 1.c -pedantic-errors -Wall -Wextra`, it might give you an error/warning if this is an extension. (Haven't tested) – mediocrevegetable1 May 18 '21 at 13:35
  • for what its worth, both MSVC's link and LLVM's lld fail to link and throw a duplicate symbol error. Clang also warns about non-static global variables when nothing refers to it with -extern. – lulle2007200 May 18 '21 at 14:18
  • 1
    Congratulation for the nicely laid down question. – linuxfan says Reinstate Monica May 18 '21 at 15:54
  • Re “-fcommon which is the default behaviour in gcc”: No, it is not. It was prior to GCC 10, but it is not now. So this is also stale: “Above compiles fine with `gcc 0.c 1.c` without any link errors”; this code will get link errors in current versions. – Eric Postpischil May 20 '21 at 23:32

1 Answers1

4

Analysis of the code according to the C Standard

This is covered in section 6.9/5 of the latest C Standard:

Semantics

An external definition is an external declaration that is also a definition of a function (other than an inline definition) or an object. If an identifier declared with external linkage is used in an expression (other than as part of the operand of a sizeof or _Alignof operator whose result is an integer constant), somewhere in the entire program there shall be exactly one external definition for the identifier; otherwise, there shall be no more than one.

The term "external definition" should not be confused with "external linkage" or the extern keyword, those are are entirely different concepts that happen to have similar spelling.

"external definition" means a definition that is not tentative, and not inside a function.

Regarding tentative definition, ths is covered by 6.9.2/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.

So in your file 1.c, as per 6.9.2/2 the behaviour is exactly as if it had said int i = 0; instead. Which would be an external definition. This means 0.c and 1.c both behave as if they had external definitions which violates the rule 6.9/5 saying there shall be no more than one external definition.

Violating a semantic rule means the behaviour is undefined with no diagnostic required.

Explanation of what "undefined behaviour" means

See also: Undefined, unspecified and implementation-defined behavior

In case it is unclear, the C Standard saying "the behaviour is undefined" means that the C Standard does not define the behaviour. The same code built on different conforming implementations (or rebuilt on the same conforming implementation) may behave differently, including rejecting the program , accepting it, or any other outcome you might imagine.

(Note - some programs can have the defined-ness of their behaviour depend on runtime conditions; those programs cannot be rejected at compile-time and must behave as specified unless the condition occurs that causes the behaviour to be undefined. But that does not apply to the program in this question since all possible executions would encounter the violation of 6.9/5).

Compiler vendors may or may not provide stable and/or documented behaviour for cases where the C Standard does not define the behaviour.

For the code in your question it is common (ha ha) for compiler vendors to provide reliable behaviour ; this is documented in a non-normative Annex J.5.11 to the Standard:

J.5 Common extensions

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).

It seems the gcc compiler implements this extension if -fcommon switch is provided, and disables it if -fno-common is provided (and the default setting may vary between compiler versions).

Footnote: I intentionally avoid using the word "defined" in relation to behaviour that is not defined by the C Standard as it seems to me that is one of the cause of confusion for OP.

M.M
  • 138,810
  • 21
  • 208
  • 365