[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Bruno Haible
Subject: Re: [Tinycc-devel] enforced immutability - proposed research project
Date: Tue, 19 Jan 2021 16:39:26 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-197-generic; KDE/5.18.0; x86_64; ; )

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]