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'?
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
