Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Does extern "const" allocate storage?
Message-ID: <1988Mar17.175448.521@utzoo.uucp>
Organization: U of Toronto Zoology
References: <7712@apple.Apple.Com>
Date: Thu, 17 Mar 88 17:54:48 GMT

> const int foo = 3;
> 
> then I hope that the compiler would actually use the constant 3 whenever foo
> is used, instead of allocating storage and generating a reference to foo.

Conceptually that declaration allocates space for an int that cannot be
assigned into, and initializes it to 3.  A halfway-intelligent compiler
will notice that the value isn't going to change, and use the constant
instead of a variable access when foo appears *in that file*.  References
from other files will have to access the variable, since the compiler has
no way of knowing the value when compiling them.

> One exception, however, would be if I declare
> 
> const int *bar = foo;
> 
> which would have to allocate storage for foo...

No, *you* have to allocate storage for whatever bar points at.  The compiler
will not do it for you.  All the above declaration asks for is that the
value foo be placed into the constant pointer bar.

> ... The ANSI C draft of 1/11/88 mentions the const type qualifier
> in section 3.5.3 but doesn't actually define its meaning...

I think you will find that the meaning is well-defined but you're going
to have to read quite a bit of the standard to catch all the nuances;
it's not all in one place.

> And while we're
> discussing that section, can someone translate their definition of noalias
> into English for me? ...

An idiomatic translation is easy:  "We want to do something about this, but
we don't understand the problem or the solutions well enough to do it right.
We'll try anyway."  :-(

More literally, ignoring fine points, the basic idea is that in the presence
of noalias, the compiler is allowed to cache variables without worrying about
whether the variables pointed at by two separate pointers really are the
same variable.  After it's all over, any altered cache entries get written
back to real memory, and if two cache entries get written back to the same
place (i.e. they *were* the same variable), the result is anyone's guess.
The idea is fine, but nobody really understands the implications well enough
to be sure it's being done right.  X3J11 has violated its own rules about
not adopting untried and poorly-understood inventions.
-- 
Those who do not understand Unix are |  Henry Spencer @ U of Toronto Zoology
condemned to reinvent it, poorly.    | {allegra,ihnp4,decvax,utai}!utzoo!henry