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

[uso ewin]

On Mon, Jan 18, 2021 at 11:43 AM Christian Jullien <eligis@orange.fr> wrote:
>
> 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.
>

I like the idea too, but please if you do that, I would prefer a new
attribute instead of modifying the const attribute.
maybe something like __attribute__((runetime_cost)) ?
> -----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
>
>
> _______________________________________________
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel