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

[Michael Matz]

Hello,

On Tue, 19 Jan 2021, Steffen Nurpmeso wrote:

> Bruno Haible wrote in
> <2278523.dGrNHthDRc@omega>:
> |Michael Matz wrote:
> ...
> |> Okay, that's quite limited, and very easy to implement: disallow casting 
> |> away immutability and you're done.  But in this limited form you then 
> |> can't infer anything useful from this, in particular you can't infer \
> |> that 
> |> the (immutably) pointed to object is unmodified when you allow mutable 
> |> references to exist to it at the same time.
> |
> |Correct. The way I see it is:
> |  - Code that got hold of a writable pointer (wp) may do modifications to
> |    the object, as long as it wants.
> |  - Code that got hold of a read-only pointer (p) should crash when it
> |    attemps a modification through this pointer. Either the crash happens
> |    when casting 'const struct data *' to 'struct data *', or it happens
>
> memchr(3) would stop working.

memchr doesn't write, it would work just fine.  (You can't write into the 
returned pointer, of course, at least not without mapping it back to a 
writable variant).  But it's immaterial even if it wouldn't work: the 
proposal is contemplating a language extension, which might or might not 
be compatible with const qualifications.  That might (or might not) 
require appropriate variants of standard functions.

> |Very often the application lets all writable pointers to the object go 
> |out-of-scope early, such that only read-only pointers to the object \ 
> |survive. Then you have a true immutable object in the proper sense of 
> |the word.
>
> Shadow regions make this a 64-bit only thing then, i presume.

Nope, it works with 32bit just fine, it merely needs a MMU.  Of course you 
reduce the available address space, which matters more on 32bit, but many 
programs don't need 1GB of address space in regular operation.


Ciao,
Michael.