Hey. Michael Matz wrote in <alpine.lsu.2.21.2101201522290.24...@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) _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel