GCC Undefined Behavior Sanitizer

[eles via Digitalmars-d]

On Sunday, 19 October 2014 at 10:45:31 UTC, Ola Fosheim Grøstad 
wrote:
> On Sunday, 19 October 2014 at 09:04:59 UTC, eles wrote:

I mostly agree with all that you are saying, still I am aware 
that much effort and coordination will be needed. OTOH, this 
would give D (and/aka the future of computing) a non-negligeable 
edge (being able to optimize across libraries).


> Some binary format allow extra meta-info, so it is possible… in 
> the long term.

Debug builds could be re-used for that, with some minor 
modifications, I think.

>> Another idea would be to simply make the in and out contracts 
>> of a function exposed in the corresponding .di file, or at 
>> least a part of them (we could use "public" for those).
>
> That's an option. Always good to start with something simple, 
> but with an eye for a more generic/powerful/unified solution in 
> the future.


I think it would not turn that bad. For the time being, putting 
the contracts in the .di files would cost barely nothing (but 
disk space). And, progressively, the compiler could be made to 
integrate those, when the .di files with contracts are available, 
in order to optimize the builds. It would be directly D code, so 
very easily to interpret. Basically, the optimizer would have the 
set of the asserts that limit the behaviour of that function at 
his hand.

Anybody else who would like to comment on this?

> But D3

People here traditionally don't like that word, but it has been 
unleased several times on the forum. Maybe not that stringent 
need, but I think that a somewhat disruptive "clean, clarify and 
fix glitches and bad legacy" release of D(2) is more and more 
needed and quite accepted as a good thing by the community (which 
is ready to take the effort to bring code up to date).