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...@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