[bitc-dev] BitC 0.20: Immutable, const, and readonly

Michal Suchanek hramrach at centrum.cz
Wed Mar 10 15:39:15 PST 2010

On 11 March 2010 00:14, Jonathan S. Shapiro <shap at eros-os.org> wrote:
> First, I wrote a bad example, and thanks to Michal for correcting me.
>    SomeStruct *const is indeed a constant field containing a pointer.
>    const SomeStruct * is a field pointing to a shallow read-only structure.
> Michal is also correct that the entire const notion in C is advisory
> and subject to being cast away. I wasn't trying to appeal to the C
> type system here; I was only trying to express the problem in a
> language syntax that everyone here presumably knows already.
> On Wed, Mar 10, 2010 at 1:59 PM, Michal Suchanek <hramrach at centrum.cz> wrote:
>> In the general case anything on RHS of an assignment can be non-const.
> It is true that the RHS of an assignment can be non-const, but that is
> not the general case. A more precise statement is that if an
> assignment targets a slot having type (mutable S), where S is a value
> type, then the expression on the RHS of the assignment must produce a
> result that is copy-compatible with (shallow-readonly S). That is: the
> type of the assignment operator is:
>   Assign(mutable S by reference, shallow-readonly S by reference)

Yes, that gives a more precise description of the assignment operator.

I don't see where this description is actually useful but it certainly
more precise than

Assign(mutable S by reference, mutable S by reference)

and somewhat easier to express (and still more precise) than

Assign(mutable S by reference, mutable unless simple S by reference)

>> Interoperability with other languages is a nice thing but again: what
>> does it give us to have a name for a half-working feature of some
>> other language?
> Serious answer: the ability to clearly express the fact that we are
> constrained by a deficient contract, and must be aware of its
> deficiencies.

And the serious question is: do we care in the cases when the contract
is deficient?

There are clearly two deficiencies here, const structs containing
pointers or similar const backdoors and the ability to cast const data
to non-const in C.

The former can be easily detected and the latter can be prevented by
compiler flags but can be still broken by inline assembly, external
libraries, and whatnot. C is simply not safe.

>> SomeStruct * const p is also called reference by another name...
> The SomeStruct * is the reference. The "p" is the containing field,
> and the constant-ness of that field has nothing to do with whether the
> SomeStruct * is a reference.

In some cases (C++ at least) there is a distinction between a
reference which names a particular object and cannot ever point to a
different object and in fact need not be actually stored anywhere and
a pointer which is a field containing a reference which can be updated
with a different reference, incremented, etc.



More information about the bitc-dev mailing list