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

[Steffen Nurpmeso]

Hey.

Michael Matz wrote in
 <alpine.LSU.2.21.2101201522290.24125@hell6.fritz.box>:
 |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 

Sorry then i misunderstood.  I would not have known how that
should have worked.  I thought code would be generated in place of
casts.

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

Well .. maybe you are right.  You could simply mmap(2) around
until you get the region you need _now_ plus guard (i think) plus
the shadow at the correct distance; ie likely one large thing then
mprotect guard and shadow region.  Like this you would only
require the memory that is really needed.  That is fine.  Well
yes, i was more thinking about an initial large split and that
would be hard; under the impression that projects like FreeBSD
even think about throwing away 32-bit because clang does not make
it there (or they enlargened space available for user space in
order to get there, or both).

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