Re: [Tinycc-devel] enforced immutability - proposed research project

[Elijah Stone]

> Silly question, putting immutable objects in a read only section is not 
> enough?

First problem: const objects can be initialized at runtime.  For example,

const int x = printf("moo")

they just can't be modified _after_ being initialized.  So it would turn 
into something like:

int tmp = printf("moo")
mprotect(&x ... PROT_READ|PROT_WRITE)
memcpy(&x, &tmp)
mprotect(&x ... PROT_READ)

(Obviously compile-time constant values can be put into rodata.  But I 
think most of the _interesting_ use of const involves runtime 
computation.)


Second problem: you can access a non-const object through a const one. For 
example:

int x;
int *mx = &x;
const int *ix = &x;
*ix = 5;

This is actually guaranteed to work in c, but for a (new, hypothetical) 
'immutable' qualifier I don't think it would make sense to allow it. 
Because it's still permitted to change the value of x through mx, we 
cannot simply map x as read-only, we have to have additional runtime 
instrumentations.  Obviously '*ix = 5' can be statically disallowed. But 
we still have to keep track of pointer provenance, for example:

int x;
const int *ix = &x;
int *new = ix;      //ok
something(*new);    //ok
*new = something;   //not ok

 -E

P.S. another idea: enforced 'restrict'?