On Mon, Jan 18, 2021 at 11:43 AM Christian Jullien <eli...@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...@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 _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
