Is having global variables in common blocks an undefined behaviour?

Question

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?

Answer 1

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.