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

[Steffen Nurpmeso]

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.

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

Shadow regions make this a 64-bit only thing then, i presume.

'Just got a bug report that requires a new version of my mailer,
on Solaris Jörg Schilling discovered a pointer that resulted from
object bit-copy that pointed to stack, and whereas on Linux (even
with -fsanitize, thus .. shadow region i think) and BSD that just
works (no access actually results) on Solaris this caused a crash
due to different memory layout.  What i want to say is possibly
that it should be possible to define positive and negative offsets
of the region, in order to avoid that codepaths like
  if(a + b < c)
never trigger.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)