Why don't free functions in implementation files have internal linkage by default?

Question

When it comes to functions (non-member functions in C++), marking them as static gives them internal linkage. This means that they are not visible outside the translation unit. Why isn't this the default? I don't have a good statistic but from what I've seen most functions in implementation files should be marked as static.

I believe the consensus is to split functionality into smaller units. So it makes sense that in general the number of "utility"-like functions in the implementation file that should not be visible in other translation units is greater than the number of functions that just are an implementation of the public interface.

What is the reason as to why they went with "export everything" by default in this context?

Answer 1

In the C/C++ compilation model, the preprocessor runs before everything else, and replaces #includes with their contents.

Hence, there's no difference between a function that's defined in a .cpp file and a function defined in a header it includes.

Your suggestion would make functions defined in headers static by default (which would remove the "mulitple definition" linking error), which would be very bad, as it would cause silent code duplication in the resulting binary if you forget inline (in C++) or if you don't know you're not supposed to define functions in headers (in C).

Answer 2

1. C part

   C is now a very old language (from the 1970s...) and is highly conservative. Include files are just meant to be included at the source level. Draft n1570 for C11 explicitly says:

   A source file together with all the headers and source files included via the preprocessing directive #include is known as a preprocessing translation unit. After preprocessing, a preprocessing translation unit is called a translation unit.

   That means that a conformant C compiler does not make any difference between what comes from an include and a source file, since the inclusion occurred before the compilation phase.

   This is enough for functions to receive an external linkage by default (not being declared as static).

2. C++ part

   Despite being a totally different language, C++ still assumes its inheritance from C. Specifically, the C standard library is still officially a part of the C++ standard library.

   This is probably enough for non-member function to receive the same processing by default as what they receive in C. This is of course far less important that in the C language, because C functions are actually declared as extern C. But on the other hand, non-member functions are also called namespace scoped function for a reason. And in C++, scoping is the correct way to handle the namespace pollution.

My opinion is that best practices should recommend to scope everything. You just use a named scope to get an external linkage and an anonymous one to limit scoping to the local unit. That is enough to not require changing the C default for non-member functions.

Answer 3

You would be hard pressed to find out why the default is "export everything". The language and its compilers have both evolved dramatically since its inception in the 1970s, where there are no release notes nor "working group" discussions available on the internet. "Structured programming" and goto statements were of the time; very few people were thinking about using encapsulation to minimise the shared-state complexity problem. Fortran also made functions publicly visible.

I would surmise that as the language grew in popularity, ever larger systems emerged which may have broken early editions of the linker. So some means of circumventing this needed to be introduced. For some crazy reason they chose to use static to hide functions from the linker to reduce its load (for me this is a bigger mystery as opposed to why linkage is arbitrarily public).

---

Practically, when declaring functions static, aside from denying other modules access to "internals", it's worth hiding symbols from the linker in very large programs in order to to speed up the build time and reduce memory consumption. This can become unwieldy very quickly. Instead of sprinkling the codebase with static to conceal methods, it actually makes more sense to use a compiler option to set hidden visibility as the default, then decorate the functions you do want to be visible to other modules.

In Linux you can direct the compiler to make hidden visibility the default (-fvisibility=hidden): see https://stackoverflow.com/a/52742992/1607937

In truth it's a little bit more complicated than that; there are other options that provide finer tuning of visibility. From https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Function-Attributes.html:

visibility ("visibility_type") The visibility attribute on ELF targets causes the declaration to be emitted with default, hidden, protected or internal visibility.

          void __attribute__ ((visibility ("protected")))
          f () { /* Do something. */; }
          int i __attribute__ ((visibility ("hidden")));

See the ELF gABI for complete details, but the short story is:

default

Default visibility is the normal case for ELF. This value is available for the visibility attribute to override other options that may change the assumed visibility of symbols.

hidden

Hidden visibility indicates that the symbol will not be placed into the dynamic symbol table, so no other module (executable or shared library) can reference it directly.

internal

Internal visibility is like hidden visibility, but with additional processor specific semantics. Unless otherwise specified by the psABI, GCC defines internal visibility to mean that the function is never called from another module. Note that hidden symbols, while they cannot be referenced directly by other modules, can be referenced indirectly via function pointers.

By indicating that a symbol cannot be called from outside the module, GCC may for instance omit the load of a PIC register since it is known that the calling function loaded the correct value.

protected

Protected visibility indicates that the symbol will be placed in the dynamic symbol table, but that references within the defining module will bind to the local symbol. That is, the symbol cannot be overridden by another module.

Not all ELF targets support this attribute.

(also see Peter Cordes' comment in the thread)

---

Also note that functions can be overridden by "bolt-on" implementations that can be linked in. This is useful for mocking methods in unit tests. It's worth using the "weak linkage" attribute if you intend to use this.

---

It's worth mentioning that in C++ it is preferred to use anonymous namespaces instead of static to declare symbols as being "private":

namespace {
    <module-private code>
} // anonymous namespace

See core guidelines SF.22 - https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rs-unnamed2

In my experience, many companies embrace this in their coding standards.

Note that is not exactly equivalent to "static":

static and anonymous namespace are not the same thing. A function defined in an anonymous namespace will have external linkage. But it is guaranteed to live in a uniquely named scope. Indeed we can't refer to it outside of the translation unit it is defined in because it is unnamed.

... so for very large C++ programs it's still worth using -fvisibility=hidden and decorate the methods you do want to be visible to the linker, even with using anonymous namespaces.

Answer 4

Functions with static keyword declared in global namespace scope would have local linkage. This mean, that

a) if they are declared in a .cpp file, they cannot be accessed from any other compilation unit (other .cpp file).

b) if they are declared in a header, there would be a copy of each function in every compilation unit which included that header file.

c) in they are declared in a module, they cannot be accessed from anywhere else.

Why the language is designed this way? It was original decision, both in C and C++. In C header files were a secondary, an optional item. You can link a program with zero header files in it. In C++ you would need prototypes of function to be declared in source code before use. In C you didn't need even that.

C++ uses same strategy. You could say it follows principle of least surprise. It would be unexpected for those functions to have local linkage by default and to require an "extern" keyword ( or "export", or some other extended abomination). In C++ anonymous namespaces act as a closest analog to "default local linkage".

Answer 5

The compiler doesn't see "definition in source file, no declarations in header". All it sees is "definition in translation unit". Under your scheme you'd need to give external linkage to every function you intend to use in multiple translation units.

The default makes lots of sense for C, where there are only free functions, and that was kept in C++ for backwards compatibility.

Answer 6

If it will be desirable to let programmers declare two slightly different forms of a construct, using a syntactic marker to distinguish an "alternate" form from a primary form, there two at least two sensible ways one could decide which form should be the primary form:

1. If one form will be used more than the other, make that the primary form.

2. If the language would be useless without one form, but would be at least somewhat usable without the other, make the first one the primary form.

If one is trying to minimize the amount of effort required to "bootstrap" a compiler onto a new platform, one should seek to omit things that aren't absolutely necessary to get a minimal compiler up and running. If a compiler will be generating code that needs to interact with any other code that's already up and running, support for external linkage will be absolutely required. Support for internal linkage may be nice, but far less necessary.