[bitc-dev] BitC 0.20: Immutable, const, and readonly
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
And the serious question is: do we care in the cases when the contract
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