[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Elijah Stone
Subject: Re: [Tinycc-devel] enforced immutability - proposed research project
Date: Mon, 18 Jan 2021 01:54:05 -0800 (PST)

Silly question, putting immutable objects in a read only section is not enough?

First problem: const objects can be initialized at runtime.  For example,

const int x = printf("moo")

they just can't be modified _after_ being initialized. So it would turn into something like:

int tmp = printf("moo")
mprotect(&x ... PROT_READ|PROT_WRITE)
memcpy(&x, &tmp)
mprotect(&x ... PROT_READ)

(Obviously compile-time constant values can be put into rodata. But I think most of the _interesting_ use of const involves runtime computation.)

Second problem: you can access a non-const object through a const one. For example:

int x;
int *mx = &x;
const int *ix = &x;
*ix = 5;

This is actually guaranteed to work in c, but for a (new, hypothetical) 'immutable' qualifier I don't think it would make sense to allow it. Because it's still permitted to change the value of x through mx, we cannot simply map x as read-only, we have to have additional runtime instrumentations. Obviously '*ix = 5' can be statically disallowed. But we still have to keep track of pointer provenance, for example:

int x;
const int *ix = &x;
int *new = ix;      //ok
something(*new);    //ok
*new = something;   //not ok


P.S. another idea: enforced 'restrict'?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]