1 Oct
2024
1 Oct
'24
12:14 a.m.
On Sep 30, 2024, at 1:03 PM, Rich Salz <rich.salz(a)gmail.com> wrote:
On Mon, Sep 30, 2024 at 3:12 PM Steffen Nurpmeso <steffen(a)sdaoden.eu> wrote
noone ever told them that even the eldest C can be used in a safe
way;
Perhaps we have different meanings of the word safe.
void foo(char *p) { /* interesting stuff here */ ; free(p); }
void bar() { char *p = malloc(20);
foo(p);
printf("foo is %s\n", p);
foo(p);
}
Why should I have to think about this code when the language already knows what is wrong.
The language doesn't know! The compiler can't know without the programmer
indicating this somehow, especially if foo() is an extern function.
I am still interested in making C safer (to secure as best as possible
all the zillions of lines of C code in OS kernels). The question is, can
we retrofit safety features into C without doing major violence to it
& turning it into an ugly mess? No idea if this is even feasible but seems
worth exploring with possibly a great ROI.
Take the above code as an example. It is "free()" that invalidates the
value of its argument on return and this property is then inherited by its
callers. One idea is to declare free as follows:
void free(`zap void*ptr); // `zap is says *ptr will be invalid on return
Now a compiler can see and complain that foo() will break this and
insist that foo() too must express the same thing. So we change it to
void foo(`zap char* p) { ... free(p); }
Now the compiler knows p can't dereferenced after calling foo() and can
complain on seeing p being printf'ed.
This was just an example of an idea -- remains to be seen if it amounts to
anything useful. In an earlier email I had explored bounds checking. Clearly
all such extensions would have to play well together as well as with the
existing language. My hope is that the language can be evolved in this way
and gradually kernel code can be fixed up to benefit from it.
Bakul