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