Tim Rühsen wrote: > the use cases are mostly in the testing area (especially fuzzing).
Indeed. During fuzzing, you want to check against any kind of buggy/undefined behaviour, and writing into arbitrary memory is one of these kinds. This brings up the question: Should such as facility be in a Sanitizer and not in a library? I think the answer is "no", because - Writing into a string is not invalid in C. Even casting a 'const char *' to 'char *' and then writing into it is valid. The reason is that the C standard only makes statements about a program as a whole and therefore cannot express constraints such as "function A is allowed to write into the memory object M but function B is not". - Integer overflow checking, for example, is available in both the Sanitizers and library code. Apparently it is useful enough that some applications want to have it enabled in production code. I believe the same will be true for immutables string or memory regions. > As a more general approach, a function that switches already allocated > memory into read-only memory would be handy. Like in > - m = malloc() > - initialize m with some data > - if in debug mode: call memmap_readonly(m) - from this point on 'm' is > read-only and a write leads to a segmentation fault. > - ... > - free(m) Hardware has write barriers only on the page level. You can't easily request a write barrier for a requence of, say, 30 bytes. To accomodate this, the API needs to have a certain shape. Paul wrote: > p = immalloc (sizeof *p); > p->x = whatever; p->y = something; ... > imfreeze (p, sizeof *p); > [no changes to *p allowed here] > imfree (p); The third line needs to be something like p = imfreeze (p, sizeof *p); because the "writable p" and the "read-only p" will be at different virtual addresses. Bruno