Type safety could prevent nuclear war

tsbockman via Digitalmars-d digitalmars-d at puremagic.com
Thu Feb 4 23:31:34 PST 2016


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?

>> 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.

>> 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.


More information about the Digitalmars-d mailing list