llvm's SAFECode bounds checking algorithm

[Timon Gehr]

On 08/21/2011 12:55 PM, Robert Clipsham wrote:
> On 20/08/2011 16:40, Walter Bright wrote:
>> http://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf
>>
>> What it does is rewrites the program to install runtime checks on
>> pointers to ensure no array bounds overflows.
>>
>> It indicates to me the effort being poured into C to try to make it
>> memory safe, and how memory safety has become a huge issue in
>> programming. We are on the right track with D with our focus on making D
>> proveably memory safe.
>
> <pushingTheBoatOut>
>
> Given that a large part of D should be writable using @safe, perhaps we
> should look into making @safe default and having to explicitly write
> @system or @trusted for a function? This is obviously a no-go in D's
> current state (most of phobos/druntime aren't appropriately annotated
> and I believe there are a good few things that @safe forbids but
> could/should permit), but it would be cool to say "D is memory safe by
> default, the programmer has to explicitly state if it's not". Perhaps
> this could be done with a compiler switch for now to see how well it
> works in the real world/evaluate whether it's actually doable/what needs
> doing to make it doable.
>
> </pushingTheBoatOut>
>

If @safe is declared the default, first @safe, and attributes/storage 
classes in general, need to be properly redesigned and implemented imho.

Eg:

int main()@safe{
     int a;
     //auto p=&a;     // disallowed by dmd
     auto p=&(0?a:a); // allowed by dmd
}

I have filed a bug for this.


alias @system int F();
@safe:
int foo() @system;
static assert(is(typeof(foo)!=F));

and

@safe:
int foo() @system;
alias @system int F();
static assert(is(typeof(foo)==F));


The compiler does not currently catch this, because afaik the _parser_ 
is responsible for the detection of conflicting storage classes. I'd say 
that a declaration of the form

@safe:
int foo() @system;

should actually compile, but make foo a @system function. Then eg: a 
module with @safe as the default could be made by just adding '@safe': 
at its beginning. (or, if safe ends up being the default, the same would 
hold for @system:)

What _does_ work on the other hand is
@safe:
@system: int foo(); @safe:


There are also such monsters as

pure alias int F();

and

alias auto bar=1;


I really think the way STCs are handled needs a (re)design.