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) _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel