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

[Christian Jullien]

I clearly like the idea, hope the maintainers will agree too.
If possible changes should be limited to few locations, better if in a single 
file and use a configure option --with-immutability or alike

C.

-----Original Message-----
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange.fr@nongnu.org] On 
Behalf Of Elijah Stone
Sent: Monday, January 18, 2021 10:54
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] enforced immutability - proposed research project

> 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