3

Am I right in saying linkers make no function parameter checks. They do not check the number or types of function calls nor do they check the type of global data references. Is this true for all linkers?

I'm using Clang targeting Linux on x86-64. Does the linker check that references are in the right segment? Or is an external reference in effect just a void * as far as the linker is concerned?

I'm coming from a high level language background C# and Scala, so this may seem obvious to those that have immersed themselves in the low level world. I've written a couple of my functions (system calls) in assembler and I noticed there were no parameter prototypes for external functions in the assembler.

Context: I'm actually writing a compiler. For the moment I'm targeting preprocessed C .i files with assembler functions for system calls, but the alternatives are C++, assembler or even machine code, so I'm trying to weigh the costs and benefits, particularly the type checking, of the assembler / compiler / linker I can use to check the correctness of my own programme and its function prototype generation.

Rich Oliver
  • 6,001
  • 4
  • 34
  • 57
  • 1
    Presumably you never would have gotten that far with those types of errors, the compiler would have thrown errors before linking ever started. – Cory Kramer Jan 22 '15 at 14:12
  • 1
    Cyber is right - in principle, linkers deal only in addresses (and symbol names, of course). – 500 - Internal Server Error Jan 22 '15 at 14:15
  • 9
    In C++, names are (usually?) mangled with types, so a type mismatch will result in a failure to find the symbol: this is mostly because of the ability to overload functions. I don't know about non-function variables, I never ran into issues there. The link-stage of C++ is underspecified and the mangling is inconsistent (in actual practice! Different compilers mangle symbols in different ways), so I cannot say more than usually. In C, they are (usually?) not manged with types, as overloading is not possible. I don't know enough of the link-stage specification of C, but it is more consistent. – Yakk - Adam Nevraumont Jan 22 '15 at 14:17
  • 1
    Related: http://stackoverflow.com/questions/27777071/is-int-main-a-valid-c-c-program – Iwillnotexist Idonotexist Jan 22 '15 at 14:24
  • The only check normally linkers do is for pointer types to check if they are the same size (so for example you don't link a 32bit module into a 64bit program or vice versa) As it has been pointed out, prototype mangling is done to allow for overloading in C++ so names don't appear as they are written in source code. – Luis Colorado Jan 23 '15 at 14:44

3 Answers3

9

As @Yakk explained, functions can be overloaded based on their parameters, and so the compiler generates mangled function names that include information about parameters and their types. The linker mostly just checks symbol names and sizes, but since mangling ensures that functions' names are different, mismatched parameters won't link.

Function return types aren't part of the mangling (because overloading on return type isn't legal), so if you declare int test() in one translation unit and call float test() in another, the linker won't catch it, and you'll get bad results.

Similarly, the types of global variables (and static members of classes and so on) aren't checked by the linker, so if you declare extern int test; in one translation unit and define float test; in another, you'll get bad results.

The linker can, in some circumstances, compare the size of a symbol in two different translation units and can catch a few problems in this way.

In practice, this is rarely an issue in normal C++ development, because whenever a function or variable or class is needed by >1 translation unit, you'll declare it in a header file that's included in both translation units, and the compiler will catch any errors before the linker even runs. (One instance where it can be an issue is if you're using an external, binary library and the header files you have for it don't match the library.)

Josh Kelley
  • 56,064
  • 19
  • 146
  • 246
  • 2
    In practice, this may get an issue when you're using headers file that mismatch with content of an external library. – PypeBros Jan 22 '15 at 16:00
  • @JoshKelley Thanks, any more info on the sizeof checking in different translation units? – Rich Oliver Jan 22 '15 at 16:24
  • 1
    @RichOliver - Sorry, I don't know enough details about how the linker works to know when it checks symbol sizes. I know that a simple case (`extern int x;` in one file, `char x;` in another) won't be detected; I think errors can be detected when C++ features like inline functions and template instantiations cause weak symbols to be emitted in >1 translation unit. – Josh Kelley Jan 22 '15 at 16:42
  • Another way to run into return type mismatch problem: have internal functions that aren't included in the header but then add declarations to them in the test source file. My function call was compiled to reuse the stack from the neighboring frame, with no compiler, linker, or address sanitizer errors, and a mysterious GPF in unrelated code. Bad deal IMO, unless you want an exercise in debugging memory layout. – max Nov 08 '17 at 13:57
3

In c++ all compilers implement some form of name mangling to separate overloaded functions; however as return types are not included in the mangle (usually) the same issue might exist here anyway.

In C you are correct - the linker can't check but this is really not as serious an issue as you think. Remember the compiler has already checked that the calls to a function match the headers provided so the only way to cause a problem is to have different duplicate versions of the header file compiled into two different c files that are later linked.

This is kind of hard to do accidentally (although if you manage you might end up with some really subtle errors).

Elemental
  • 7,365
  • 2
  • 28
  • 33
0

Many linkers include features to provide a some level of type checking, but the details vary. Some compilers will prefix the names of functions that use one calling convention with underscores, but omit the underscores from the names of functions that use a different calling convention; if one translation unit declares a function using one convention, but the actual function is defined using another, the program will be rejected at link time.

Some platforms (e.g. HiTech C for the PIC) allow a compiler or an assembly-language program to specify a 16-bit value when declaring or referencing a symbol, and will squawk if the point of reference supplies a value that doesn't match the definition. The C compiler generates for each function a hash value based on the combination of parameter types and return types, and the linker will squawk if an attempt is made to call a function whose signature-hash value differs at the definition and call site.

supercat
  • 77,689
  • 9
  • 166
  • 211