Type safety could prevent nuclear war

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Thu Feb 4 23:05:06 PST 2016


On Fri, Feb 05, 2016 at 04:02:41AM +0000, tsbockman via Digitalmars-d wrote:
> On Friday, 5 February 2016 at 03:46:37 UTC, Chris Wright wrote:
> >On Fri, 05 Feb 2016 01:10:53 +0000, tsbockman wrote:
> >The compiler doesn't have all the information you need. You could add it
> >to the build system or the linker as well as the compiler. Adding it to
> >the linker is almost identical to my previous suggestion of adding
> >optional name mangling to C.
> 
> What information, specifically, is the compiler missing?
> 
> The compiler already computes the name and type signature of each function.
> As far as I can see, all that is necessary is to:
> 
> 1) Insert that information (together with what file and line number it
> came from) into a big list in a temporary file.
> 2) After all modules have been compiled, go back and sort the list by
> function name.

This would make compilation of large projects excruciatingly slow.


> 3) Finally, scan the list for entries that share the same name, but
> have incompatible type signatures. Emit warning messages as needed.
> (The compiler should be used for this step, because it already has a
> lot of information about C's type system built into it that can help
> define "incompatible" sensibly.)

This fails for multi-executable projects, which may legally have
different functions under the same name. (Even though that's arguably a
very bad idea.)


> As far as I can see, this requires an extra pass, but no additional
> information. What am I missing?

The fact that the C compiler only sees one file at a time, and has no
idea which one, if any, of them will even end up in the final
executable. Many projects produce multiple executables with some shared
sources between them, and only the build system knows which file(s) go
with which executables.

So as others have said, this can only work for compilers that are aware
of the larger picture than just the single source file it's currently
compiling. Even in D, for a sufficiently large project the compiler
can't see everything at once either, because it won't fit into your RAM.
Thankfully, D doesn't suffer from this particular problem because of
name mangling.

Which is why I said, adding name mangling to the C compiler will solve
this problem. Except that it breaks existing inter-language code, so it
won't work for *all* C programs. And it will also break linkage with
existing shared libraries, which are *not* name-mangled. (Recompiling
said libraries may not be an option if they are OEM, binary-only blobs.)
So it can only work for self-contained, independent projects with no
inter-language linkage, which would be a very restricted subset of C
codebases.


T

-- 
Nobody is perfect.  I am Nobody. -- pepoluan, GKC forum


More information about the Digitalmars-d mailing list