4 ms·
C could have gained the safety of function prototypes without them. Note that the function bodies and call sites had the type information. It could have been pr
by knaq 6y ago
C could have gained the safety of function prototypes without them. Note that the function bodies and call sites had the type information. It could have been propagated through the compiler and assembler to the linker, which would then check for compatibility.
In some ways it would have worked much better. Header files can easily be wrong. The object files being linked are what really matter.
So, suppose we decided to implement this today, on a GNU toolchain. At the call site, we'd determine the parameter types based on the conventional promotions. This info gets put into the assembly output with an assembler directive. The assembler sees that, then encodes it in an ELF section. It might get a new section called ".calltype" or it is an extension to the symbol table or it involves DWARF. Similar information is produced for the function body. The linker comes along, compares the two, and accepts or rejects as appropriate.
- saagarjha 6y agoThis would require storing type information in a symbol, would it not? Either via mangling or some other method.
- knaq 6y agoYes. I proposed a method without mangling, but I suppose there isn't any reason why C couldn't use mangled names. It also isn't a requirement that C++ use mangled names. Other ways of carrying the type information are possible. I like the idea of a reference to DWARF debug info, which C++ is already using to support stack unwinding for exceptions.
- account42 6y ago> It also isn't a requirement that C++ use mangled names. Overloading requires the type information to be part of the symbol "name" (ie, whatever is used for symbol lookup and linking) wether that is a mangled string or more complex data structure.