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.
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
