Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!necntc!ima!haddock!karl From: karl@haddock.ISC.COM (Karl Heuer) Newsgroups: comp.lang.c Subject: Re: Does extern "const" allocate storage? Message-ID: <3288@haddock.ISC.COM> Date: 1 Apr 88 20:12:25 GMT References: <3117@haddock.ISC.COM> <136@polygen.UUCP> Reply-To: karl@haddock.ima.isc.com (Karl Heuer) Organization: Interactive Systems, Boston Lines: 29 In article <136@polygen.UUCP> pablo@polygen.uucp (Pablo Halpern) writes: >From article <3117@haddock.ISC.COM>, by karl@haddock.ISC.COM (Karl Heuer): >>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. > >I disagree. An object that is declared const but not volatile can not >be modified within the scope in which the declaration holds. Nowhere >does the standard say that such an object is "really constant." Footnote 50 certainly implies it. If the body of the standard doesn't say that modifying a const object through a non-const handle is undefined, I'm sure the Committee would like to correct the oversight. (Note: I'm talking about actual objects declared const. Your statement is true for a dereferenced pointer-to-const.) >In the standard, a clock register is used as an example of a volatile const. >The declaration looked something like: > extern const volatile int clock; >The meaning of this is explaned that the clock register may not be written to >by the program and that if it is read once, the value may be different if it >is read again. The question is, doesn't this imply that somewhere there is a >function that might [modify it through a non-const handle] No, the dpANS said that this may be "modifiable by hardware". A memory-mapped address could be so declared. (Presumably the linker will bind the unresolved extern to the appropriate magic location.) Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint