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

[grischka]

Bruno Haible wrote:
> Hi TinyCC hackers, hi Christian,
>
> Here is a proposal to use TinyCC for a research project in programming
> language design.
>
> Immutable objects are a well-known feature, used to protect some data
> from accidental/undesired modifications by other parts of the program.
>
> So far, in C, immutable objects are "implemented" through the 'const'
> attribute, but is not enforced at runtime (except for 'static const'
> objects, which may reside in a read-only data section if they don't
> contain relocatable pointers). Namely, any piece of the program can
> cast away the 'const' and perform on a write access through a non-const
> pointer.
>
> The project would be about enforcing immutability of immutable objects
> at runtime.

Did not 'const' start as a 'storage specifier', meant to allow
the compiler to optimize storage and hence to create more
efficient code, at some cost for the programmer who has to be
a little more careful with certain things because otherwise a
program might crash.

So, what would be the reason to make a program superficially
less efficient and the same time more likely crash?

How is this supposed to protect whom against what?  Via feedback
from users sending core dumps?  Was it not just that what we're
trying to avoid?  Is it a relevant problem in software that people
are writing casts "by accident"?  Define "undesired modification".
If I would just remove the new "immutable" attribute from something
as soon as it gets in my way, would this be "undesired modification"?

Side note: Seems we have a ".data.ro" section since recently in tcc,
however the only thing I can see that actually seems to get there is
the "static const struct pe_header pe_template;" from tccpe.c.  Even
with -Wwrite-strings.  Hmm.

Maybe if we had a feature to find any currently non-const declared
objects that still are not modified anywhere (and therefor could be
marked const), maybe that could be useful...

--- grischka

> Some people like the idea [1][2].
>
> Such a thing had been implemented for Common Lisp in GNU clisp in the
> past [3], but did not have a big success because the Common Lisp language
> specification makes most objects read-write; there is no 'const' in
> this language.
>
> But in C, 'const' is firmly rooted, and people hate to use a debugger
> and set hardware watchpoints, to detect undesired write accesses.
>
> The implementation would consist of two parts:
>
> 1) The runtime code. This code already exists in Gnulib [4][5].
>    It works on all Unix and Windows platforms (except Minix, which
>    lacks mmap() and mprotect()).
>
> 2) Compiler support. This could be tied to the 'const' attribute,
>    or a new attribute could be introduced, as proposed in [6].
>
>    I would estimate that this part can more easily be done in TinyCC
>    than in GCC or LLVM; which is why I am writing to you.
>
> I believe this would be a world's first for C: Wikipedia [7] says that
> "Immutability does not imply that the object as stored in the computer's
>  memory is unwriteable. Rather, immutability is a compile-time construct"
> This statement would be obsolete!
>
> If you like it: Have fun!
>
>           Bruno
>
> [1] https://lists.gnu.org/archive/html/bug-gnulib/2019-12/msg00234.html
> [2] https://lists.gnu.org/archive/html/bug-gnulib/2019-12/msg00232.html
> [3] 
> https://gitlab.com/gnu-clisp/clisp/-/commit/4b7ed0f7346eac7190fb5b39ccca3883f03ab8bb
> [4] https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/immutable.h
> [5] https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/immutable.c
> [6] https://lists.gnu.org/archive/html/bug-gnulib/2019-12/msg00242.html
> [7] https://en.wikipedia.org/wiki/Immutable_object#Violating_immutability
>
>
> _______________________________________________
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel