GCC Undefined Behavior Sanitizer

[via Digitalmars-d]

On Sunday, 19 October 2014 at 09:04:59 UTC, eles wrote:
> That's complicated, to provide another langage for describing 
> the behavior.

I think D need to unify UDA, type-traits, template constraints 
and other deductive facts and rules into a deductive database in 
order to make it more pleasant and powerful. And also provide the 
means to query that database from CTFE code. A commercial 
compiler could also speed up compilation of large programs with 
complex compile time logic. (storing facts in a persistent high 
performance database)

There are several languages to learn from in terms of specifying 
"reach" in a graph/tree structure. E.g. XQuery

You can view  "@nogc func(){} " as a fact:

nogc('func).

or perhaps:

nogc( ('modulename,'func) ).

then you could list the functions that are nogc in a module using:

nogc( ('modulename,X) )

Same for type traits.

If you build it into the typesystem then you can easily define 
new type constraints in complex ways.

(You could start with something simple, like specifying if values 
reachable through a parameter escape the lifetime of the function 
call.)

> And how? Embedded in the binary library?

The same way you would do it with C/C++ today.

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

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

> Anyway, as far as I ca imagine it, it would be like embedding 
> Polyspace inside the compiler and stub functions inside 
> libraries.

Yes, or have a semantic analyser check, provide and collect facts 
for a deductive database, i.e.:

1. collect properties that are cheap to derive from source, build 
database

2. CTFE: query property X

3. if database query for X succeeds return result

4. collect properties that are more expensive guided by (2), 
inject into database

5. return result

> For source code. But for cloused-source libraries?

You need annotations. Or now that you are getting stuff like 
PNACL, maybe you can have closed source libraries in a IR format 
that can be analysed.

>> 3. Remove int so that you have to specify the range and make 
>> typedefs local to the library
>
> Pascal arrays?

subrange variables:

var
age : 0 ... 150;
year: 1970 ... 9999;


>> Lots of opportunities for improving "state-of-the-art".
>
> True. But a lot of problems too. And there is not much 
> agreement on what is the state of the art...

Right, and it get's worse the less specific the use scenario is.

What should be created is a modular generic specification for a 
system programming language, based on what is, what should be, 
hardware trends and theory. Then you can see the dependencies 
among the various concepts.

C, C++, D, Rust can form a starting point.

I think D2 is to far on it's own trajectory to be modified, so I 
view D1 and D2 primarily as experiments, which is important too.

But D3 (or some other language) should build on what the existing 
languages enable and unify concepts so you have something more 
coherent than C++ and D.

Evolution can only take you so far, then you hit the walls set up 
by existing features/implementation.