Aren't static variables limited to the compilation unit? - c

Question

I have the following files:
main.c:
#include "ext.h"
#include "main2.h"
#include <stdio.h>
int main () {
// printf("main - internal_static_variable: %d\n", internal_static_variable);
// printf("main - internal_static_variable: %d\n", internal_static_variable);
printf("main - external_variable: %d\n", external_variable);
put_static_val(24);
put_val(42);
printf("main - internal_static_variable: %d\n", get_static_val());
printf("main - internal_variable: %d\n", get_val());
++external_variable;
print();
}
main2.h:
// main 2.h
#pragma once
void print();
main2.c:
// main2.c
#include "ext.h"
#include "main2.h"
#include <stdio.h>
void print() {
printf("main2 - external_variable: %d\n", external_variable);
printf("main2 - internal_static_variable: %d\n", get_static_val());
printf("main2 - internal_variable: %d\n", get_val());
}
ext.h:
// ext.h
#pragma once
extern int external_variable;
void put_static_val(int v);
int get_static_val();
void put_val(int v);
int get_val();
ext.c:
// ext.c
#include "ext.h"
static int internal_static_variable = 0;
int internal_variable = 1;
int external_variable = 2;
void put_static_val(int v) {
internal_static_variable = v;
}
int get_static_val() {
return internal_static_variable;
}
void put_val(int v) {
internal_variable = v;
}
int get_val() {
return internal_variable;
}
When compiled and executed, the result is the following:
main - external_variable: 2
main - internal_static_variable: 24
main - internal_variable: 42
main2 - external_variable: 3
main2 - internal_static_variable: 24
main2 - internal_variable: 42
As expected, the variables not exposed in the header file (internal_static_variable and internal_variable) are not directly accessible.
What I don't get is the meaning of static. I know it limits the scope of a variable to the compilation unit, but isn't it enough not to declare a variable in the header file to hide it?
Also, I assumed that the static variable and the not-static variable would behave differently. Specifically, internal_static_variable would not be shared by the files including it (one instance for main.c and one for main2.c), but since I change its value from main.c and I get the changed valued in main2.c, there seems not to be any difference between the two.
Could you explain it, please? Thanks

Answer 1

Scope and Linkage
Identifiers have two properties that are relevant here: scope and linkage.
Scope is where an identifier is visible. You apparently already know that scope is limited to the file an identifier is declared in, and it may be further limited to a block or a function (or a function prototype) depending on where the identifier is declared and the keywords (such as static or extern) used when declaring it.
Linkage is a way of making different declarations of an identifier refer to the same object. There are three types of linkage: external, internal, and none.
If an identifier has internal linkage, it is not linked with identifiers in other translation units. An object called foo in one translation unit1 cannot be accessed by name in another translation unit.2
If an identifier has external linkage, it can be accessed in another translation unit by declaring an identifier with the same name and also with external linkage. When the program is linked together, identifiers with external linkage are resolved by the linker so that they refer to the same storage.
Problems With External Linkage
You can omit static and leave your identifiers with external linkage. As long as you are the only person writing your program, you can avoid problems. But this is not tidy; it leaves some things dangling, which can cause problems.
If you are writing routines to be used in other programs, leaving private identifiers with external linkage can be a problem, especially if they have simple, common names. A person who is using your routines in their own code might use the same name coincidentally, and then your two identifiers would be linked to the same object even though you need them to be different.
This can also occur intentionally. If you write a popular software package and leave private names with external linkage, some users of the package may explore what names are present and try to use them. This can result in people creating software which makes use of things in your software that were supposed to be private. Then you cannot develop new versions of the software that change the private parts without breaking existing software. That becomes a business problem. You may need to implement new algorithms inside the software package, but you do not want to break the existing source code of your customers. Declaring the names with static originally could avoid that.
How Declarations Affect Linkage
When an identifier is declared with static at file scope, it has internal linkage. Beyond that, the rules for which linkage an identifier has are a bit complicated, due in part to history of how the C language developed:
Declaring an identifier with extern gives it external linkage if no prior declaration is visible.
If there is a visible prior declaration, extern leaves the identifier with the same linkage as in the previous declaration.
A declaration of a function or an object at file scope without extern or static gives the identifier external linkage.
A declaration of an object at block scope without extern has no linkage, even if static is used.
Function parameters have no linkage.
Identifiers of things that are not objects or functions (such as type definitions) have no linkage.
Within one translation unit, each declaration of an identifier with internal linkage denotes the same object or function. Each declaration of an identifier with no linkage denotes a unique entity. (This paragraph is a direct quote from C 2011 [N1570] 6.2.2, and the other information in this answer comes from there too.)
Footnotes
1 A translation unit is the combined source code resulting from all #include directives. I use the technical term “translation unit” rather than “source file” because an object called foo in one source file could be accessed in another source file by using the #include directive.
2 An object with internal linkage can still be accessed in another translation unit by using a pointer, if you pass its address from one function to another.

Answer 2

If you define a non-static global variable, it's still global. Even if it's not declared in a header file, it can still be declared in another translation unit.

Answer 3

When a variable is extern (the default), the object file generated by this compilation unit will carry a named reference to its location. Whenever another object file is linked with the first and refers to the same named variable but does not provide its own definition, the linker will replace all instances of its use of that variable with its location. The CPU deals with memory locations during execution not variable names. This is why it being omitted in the header does not matter; later when you link the object files created from your .c source files, only then are global references resolved.
Static (outside of functions) is useful in that a single library/program can have multiple globally accessible variables under the same name. This prevents name collisions between modules which may both use a variable name for different purposes but make sense in their own contexts to use a variable name which just happens to be the same. As long as the variable is only needed in the current compilation unit, then you should make it static.

Answer 4

What I don't get is the meaning of static. I know it limits the scope
of a variable to the compilation unit, but isn't it enough not to
declare a variable in the header file to hide it?
That would not prevent the variable being declared and therefore becoming accessible. It is the difference between security and obscurity. By declaring it static it cannot be accessed externally by name, by simply not declaring it in a header you are only preventing access to those who do not know its name and data type. A more likely scenario is that your object code or library is used elsewhere and you get an accidental name clash - such bugs are often difficult to fathom.
I assumed that the static variable and the not-static variable would
behave differently. Specifically, internal_static_variable would
not be shared by the files including it (one instance for main.c and one for main2.c), but since I change its value from main.c and
I get the changed valued in main2.c, there seems not to be any
difference between the two.
Your code does not modify internal_static_variable in main.c; it modifies it only in ext.c. ext.c happens to expose internal_static_variable through an accessor function, which in your example provides minimal protection, but as a single point of write access, provides a number of advantages over direct access to the variable, such as:
It is possible to include code in the accessory to handle invalid input, by asserting, returning an error value, aborting, ignoring the value and not modifying the variable, or coercing to a valid value for example. Such code might also be conditionally compiled so that it only performs checking in a debug build.
The accessor function provides a single point in the code to place a debugger breakpoint to trap all write accesses.