Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!att!dptg!ulysses!andante!alice!shopiro
From: shopiro@alice.UUCP (Jonathan Shopiro)
Newsgroups: comp.std.c++
Subject: Re: 'const' revisited
Summary: Retraction
Keywords: const access restrictions
Message-ID: <11200@alice.UUCP>
Date: 16 Aug 90 15:24:56 GMT
References: <26909@pasteur.Berkeley.EDU> <11194@alice.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 47

In article <11194@alice.UUCP>, I wrote:
> 
> 
> ...  E&S says only that const instances of bit-wise const
> types may be put into read-only memory, but I think it would be
> reasonable for X3J16 to extend this interpretation so that an
> implementation would be allowed to assume that a const pointer to a
> bitwise const type points to memory that will not change.
> 
Oops!!  Consider the following perfectly reasonable function:

	void
	increase(int* ip, const int* cip)
	{
		*ip += *cip;
	}

and a call to the function:

	main()
	{
		int		i = 3;
		int*		p = &i;
		const int*	cp = &i;
		increase(p, cp);
		cout << *cp << "\n";
	}

This function had better print "6", but if my unthinking proposal
were accepted, it would be permissible for it to print "3."  Of
course, in this case, the aliasing is obvious, but in general
aliasing is impossible to detect at compile time.

I would be willing to consider allowing the implementation to assume
that memory pointed to by a const pointer to a bitwise const type
points to memory that will not change, but only if the implementation
can prove that the memory cannot be changed through any legally
constructed alias.  (For example the pointer points to an automatic
variable in that function and the address of that variable has not
been saved elsewhere).

On a separate topic, I have changed my .signature but I am still the
same person.
-- 
		Jonathan E. Shopiro
		AT&T Bell Laboratories, Warren, NJ  07059-0908
		shopiro@research.att.com   (201) 580-4229