Type safety could prevent nuclear war

[H. S. Teoh via Digitalmars-d]

On Fri, Feb 05, 2016 at 07:31:34AM +0000, tsbockman via Digitalmars-d wrote:
> On Friday, 5 February 2016 at 07:05:06 UTC, H. S. Teoh wrote:
> >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:
> >>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.
> 
> It's a small fraction of the total data being handled by the compiler
> (smaller than the source code), and the list could probably be
> directly generated in a partially sorted state. Little-to-no random
> access to the list is required at any point in the process. It does
> not ever need to all be in RAM at the same time.
> 
> I can see it may cost more than it's actually worth, but where does
> the "excruciatingly slow" part come from?

OK, probably I'm misunderstanding something here. :-P


> >>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.)
> 
> Chris Wright pointed this out, as well. This just means the final pass
> should be done at link-time, though. It's not a fundamental problem
> with generating the warning.

The problem is, the linker knows nothing about the language. Arguably it
should, but as things stand currently, it doesn't, and can't, because
usually linkers are shipped with the OS, and are expected to link object
files of *any* pedigree without needing to code for language-explicit
checks.

Perhaps this is slowly starting to change, as LTO and other recent
innovations are pushing the envelope of what the linker can do.  Maybe
one day there will emerge a language-agnostic way for the linker to
check for such errors... but I really don't see it happening, because
languages *other* than C have already solved the problem with name
mangling. There isn't much motivation for linkers to change just because
C has some language design issues.

(And note that I'm not trying to disagree with you -- I'm totally in
agreement that what C allows is oftentimes extremely dangerous and
rather unwise. But the way things are is just so entrenched that it's
unlikely to change in the near (or even distant) future.)


> >>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.
> 
> This could be worked around with a little cooperation between the
> compiler and the linker. It's not even a feature of C the language -
> it's just the way current tool chains happen to work.

And that's where the sticky part lies. Current toolchains work in this,
arguably suboptimal, way mainly because of historical baggage, but more
because doing otherwise will make the toolchain incompatible with
existing other toolchains and systems. The current divide between
compiler and linker is actually IMO not in the best place it could be,
as it hampers a lot of what, arguably, should be the compiler's job, not
the linker's. Nevertheless, changing this means you become incompatible
with much of the ecosystem and become a walled garden -- like Java (JNI
was an afterthought, and requires a very specific setup to even work --
there's definitely no way to link Java objects with OS-level object
files without jumping through lots of hoops with lots of caveats). I
just don't see this ever happening, especially not for something that,
in the big picture, really isn't *that* big of a deal. After all, C
coders have gotten used to working with far more dangerous things in C
than merely mismatched prototypes; it would take a LOT more than that
for people to accept changing the way things work.


T

-- 
Skill without imagination is craftsmanship and gives us many useful objects such as wickerwork picnic baskets.  Imagination without skill gives us modern art. -- Tom Stoppard