Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!pacbell!att-ih!chinet!dag
From: dag@chinet.UUCP (Daniel A. Glasser)
Newsgroups: comp.lang.c
Subject: Re: Does extern "const" allocate storage?
Message-ID: <3938@chinet.UUCP>
Date: 23 Mar 88 08:37:54 GMT
References: <7712@apple.Apple.Com> <3034@haddock.ISC.COM> <613@mcrware.UUCP> <3117@haddock.ISC.COM>
Reply-To: dag@chinet.UUCP (Daniel A. Glasser)
Organization: Chinet - Public Access Unix
Lines: 58

In article <3117@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes:
>In article <613@mcrware.UUCP> jejones@mcrware.UUCP (James Jones) writes:
[original stuff deleted]
>>Is this really true [since "const" really means "readonly", not "constant"]?
>
>An object which is declared const but not volatile can never be modified by a
>correct program.  A conforming implementation is allowed to take advantage of
>this knowledge, by putting it in read-only memory and/or by inlining it.
>
>Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint

I dissagree with Karl.  I'm looking at the draft standard right now, and I
believe that const does not give the compiler the license to 'inline' it.
The January 11, 1988 draft standard says in section 3.5.3, footnote 50,
page 65:

	"The implementation may place a const object that is not volatile
	in a read-only region of storage."

The rationale of the same date is out of sync with the standard in section
numbers, and discusses this in section 3.5.2.4.  It states that the compiler
can cache this value, only reading it from storage once, though this does
not guarentee that the value will not ever change in the running of the
program.  The only time that a const value is known never to change (by
the compiler) is when it is declared as 'const noalias'.  (Note that if
dmr, and those of us who agree with him, has is way, noalias will not make
it into the final standard.)  The rationale goes on to say that they could
just as easily created a 'nonconst' qualifier instead.  The purpose of the
const qualifier is to allow diagnostics when the programmer inadvertantly
does an assignment to one, and to allow the compiler to make some assumptions
about the integrity of the data between sequence points.  The actual hardware
protection of the storage allocated to const objects is an extension, and
not directly addressed in the body of the draft standard.  (just a footnote)

What Mr. Heuer is describing is more of a 'Literal contant'.  These exist
in some other languages, but the closest thing to one in C is an enumeration
constant.  Maybe the next round of standards for C should consider the
BLISS style global literal as a new feature for the language.

Daniel A. Glasser		I've read the draft standard from cover to
Mark Williams Co.		cover, and also the rationale.  It leaves me
1430 W. Wrightwood Ave.		with a philisophical, not technical, question:
Chicago, IL 60660		
(312) 472-6659			If you dereference a NULL pointer to void,
...!ihnp4!mwc!dag				does anything happen?  (-;
				... *((void *)0)
				? Error -- Pointer is NULL and void

	(void *) wars, coming to a newsgroup near you!

PS to KH:  Please don't flame me so violently, huh?  I'm not posting out
	of spite.  And yes, our compiler converts i++ to ++i where it makes
	no difference.  I've encountered those that do not, and have learned
	not to depend on its being done.
-- 
		Daniel A. Glasser	dag@chinet.UUCP
    One of those things that goes "BUMP!!! (ouch!)" in the night.
 ...!att-ih!chinet!dag | ...!ihnp4!mwc!dag | ...!ihnp4!mwc!gorgon!dag