Re: immutable string type

[Bruno Haible]

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