Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

On Friday, 5 February 2016 at 04:25:09 UTC, Adam D. Ruppe wrote:
> On Friday, 5 February 2016 at 01:33:14 UTC, tsbockman wrote:
>> As to the ".di" stuff - I've not used them. Care to educate 
>> me? How can they cause similar problems?
>
> Well, technically, a .di file is just a .d file renamed, but it 
> tends to have the bodies stripped out. Separate compliation is 
> a supported feature of D.
>
> The way you'd do it is something like this:
>
> struct Foo {
>    float a;
>    float b;
> }
>
> void bar(Foo* f) {
>    f.b = whatever;
> }
>
>
> Then compile it with -lib and make a "header" file manually:
>
> struct Foo {
>    double a;
>    double b;
> }
> void bar(Foo*);
>
>
> You can now create D modules that import this and link against 
> the compiled library. Very similar to C's model...
>
> But I redefined Foo! The name mangling won't catch this. bar 
> will be mangled to take `Foo` as an argument and the linker 
> will catch if we change that, but it doesn't know what Foo 
> actually is.
>
> By changing that, we introduce the problem.
>
>> 314 definitely has potential. Should we start an "Underhanded 
>> D" contest? Sounds like bad marketing, but a lot of fun :-P
>
> it might be :)

Thanks for the explanation. That does sound basically the same as 
the C issue.

Since .di files are normally generated automatically, this seems 
like an easily solvable problem:

1) When compiling a library and its attendant .di file(s), 
generate a unique version identifier (such as a UUID or a hash of 
the completed binary) and append it to both the library and each 
.di file.

2) Whenever someone tries to link against the library, verify 
that the version ID matches. If it does not, issue a prominent 
warning.

Problem solved? Or is this harder than it looks?

(Of course there are various details to consider, such as how to 
efficiently share one set of .di files across many 
platforms/compiler settings; this is just a rough sketch.)