From: wmm@world.std.com (William M Miller)
Subject: Re: Committee Members -> What do you think?
Organization: Software Emancipation Technology, Inc.
Date: Sat, 25 Jul 1992 15:34:27 GMT

In article <9220718.561@mulga.cs.mu.OZ.AU>, Fergus James HENDERSON writes:
> No, I think that he means the change which clarified the wording of the ARM to
> explicitly allow cast-from-const. Apparently the previous wording was open to
> interpretation, so compilers could have made optimizations assuming that
> const really meant constant and still claim to be "ARM-compliant".
> This change was apparently never voted on; apparently it was decided on by
> the secretary (or president?) on the basis of discussion with Bjarne as to
> the original intended meaning of the ambiguous wording.

AARRGGHH!  A falsehood once told can apparently never be erased.  This
is *not* what happened, it is pure revisionist history.  The real
story is quite different.  I'll try one more time to set the record
straight.

Part of what must be understood is the difference between the
reference manual and commentary ("annotation") portions of the ARM.
The RM is, except for a few minor changes that occurred between the
adoption of the base document and the publication of the ARM, the base
document for the eventual standard.  In the case of X3J16, that meant
that the words were taken verbatim as the initial draft working paper
and changes are applied as needed.  Changes are either substantive,
i.e., changing the language definition, or editorial, i.e., just
clarifying the presentation; a higher level of scrutiny is generally
applied to changes that are substantive.  The editor is generally
encouraged to make editorial improvements at will while substantive
changes must generally originate with the Committee itself, although
the full Committee must vote to approve *all* changes to the working
paper.

The commentary in the ARM is *not* part of the text of the working
paper.  In a number of cases, the commentary makes clear something
that is unclear in the RM proper, and in these cases it is generally
felt that changing the wording of the working paper to reflect the
commentary is an editorial rather than substantive change.  The change
to the working paper concerning casting away const falls into this
category.

The ARM ontains the following description of casting away const (I'll
distinguish RM from commentary):

Section 5.4, pp 70f:
[RM]

	A pointer to an object of a 'const' type can be cast into a
	pointer to a non-'const' type.  The resulting pointer will
	refer to the original object.  An object of a 'const' type or
	a reference to an object of a 'const' type can be cast into a
	reference to a non-'const' type.  The resulting reference will
	refer to the original object.  The result of attempting to
	modify that object through such a pointer or reference will
	either cause an addressing exception or be the same as if the
	original pointer or reference had referred [to] a non-'const'
	object.  It is implementation dependent whether the addressing
	exception occurs.

[commentary]

	That is, unless the object has been stored in readonly memory
	the result of having cast away 'const' is exactly the same as
	if the object had never been specified 'const'.

Section 7.1.6, pp 109f:
[commentary]

	Adding 'const' to a declaration ensures that an object to
	which the 'const' is applied cannot have its value changed
	through an expression involving the name being declared unless
	an explicit type conversion is used to remove the "constness"
	-- and possibly even not then.  It is worth remembering,
	however, that there may be other ways of referring to the
	object and that explicit type casting is possible; 'const'
	does _not_ simply mean "store in readonly member" nor does it
	mean "compile-time constant."

	...Casting away 'const' is generally ill advised since it
	violates a guarantee making a program much harder to
	understand and debug.  It can also be hazardous.  This
	variant, for example, may fail:

		const int i = 1;
		const int* p = &i;  // `i' cannot be updated through 'p'

		void h()
		{
			(*(int*)p)++;  // may be ok, may be run-time error
		}

	since 'i' might have been put in readonly memory.

[RM]

	A 'const' object of a type that does not have a constructor or
	a destructor may be placed in readonly memory.  The effect of
	any write operation on any part of such an object is
	undefined.

[commentary]

	This implies that most 'const' objects of C++ style class
	types may not be placed in readonly memory, whereas most
	'const' objects of built-in types and C style structures may.
	The purpose of this distinction is to allow the use of
	readonly memory for large tables, while still enabling
	"constness" for class objects to be defined by the programmer
	through the definition of 'const' member functions (section
	9.3).

	Note that since in most practical machine architectures memory
	cannot be made "readonly" during program execution, an object
	can be placed in readonly memory only if it is initialized by
	a value that can be determined at compile time.  For example,

		const one = 1;   // can go in readonly memory
		f(int i)
		{
			const two = i;  // cannot go in readonly memory
			// ...
		}

If you read the RM portions only, you get the impression that
implementations are free to decide whether or not to enforce a 'const'
declaration, and that they may, in fact, choose to throw an exception
if 'const' is cast away.  This is, unless I am mistaken, the position
that Jim Adcock is defending under the rubric of "Alice const."

In fact, as the annotations make clear, the reason for phrases like
"It is implementation dependent whether the addressing exception
occurs" is to allow implementations freedom *not* to place objects in
readonly memory.  The annotation on p. 71 is especially clear: "unless
the object has been stored in readonly memory the result of having
cast away 'const' is exactly the same as if the object had never been
specified 'const'."  I think this is the position vilified by Jim
Adcock as "Humpty-Dumpty const."

Because the working paper, based only on the RM, admitted of a
distinctly different interpretation from that which would be gained by
a careful reading of the ARM, the editor, Jonathan Shopiro, in
consultation with other members of the Committee, chose to make an
editorial change to the working paper.  The resulting verbiage is
(from section 7.1.6):

                                              A type which has
  no  user-defined  constructors  or  destructor  and  no base
  classes  or  members  with  user-defined   constructors   or
  destructors  is  called    ROMable  (but no objects are ever
  required to be placed in read-only memory).  The effect of a
  write  operation  on  any  part  of a const object of a non-
  ROMable type is the same as if the  object  was  not  const.
  The  effect  of  a  write  operation  on any part of a const
  object of a ROMable type (which is not a  sub-object  of  an
  object  of a non-ROMable type) is undefined.  Such an object
  may be placed in readonly memory.

To this observer, at least, this wording says exactly the same thing
as the ARM: objects of types with constructors or destructors cannot
be placed into ROM, and a write operation on such an object by casting
away const is guaranteed to succeed.

The draft working paper that first contained this wording was
considered and approved at the June, 1991, meeting of the Committee.
There was no discussion of whether it was a substantive change.  Since
such questions have arisen on several occasions regarding other
changes, the absence of such discussion in this case can be taken as
evidence that the Committee, in voting to accept the working paper,
agreed that the change was simply editorial.

The discussion regarding how 'const' *ought* to be interpreted is
valid and continues to this day, including Tom Ngo's ~const proposal.
Any attempt to portray the change to the wording of the working paper
on this subject as underhanded and an attempt to rig the results of
the discussion, however, is at best misinformed and at worst a
scurrilous attempt to rewrite history.

-- William M. Miller, wmm@world.std.com
Newsgroups: comp.lang.c++,comp.std.c++