Michael Matz wrote:
> > Many programs don't make copies of wp. The typical idiom is that the
> > function that allocates an object also fills it and selectively stores or
> > returns writable and read-only views to the object. Enforced immutability
> > should only verify that some code that received a read-only pointer does
> > not do a write access.
>
> 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
when doing writes to the cast pointer.
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.
Bruno
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
