Date: Tue, 13 Jan 1998 15:37:03 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Joel Ray Holveck <joelh@gnu.org> Cc: chrisy@flix.net, tom@sdf.com, freebsd-hackers@FreeBSD.ORG Subject: Re: sharable static arrays? Message-ID: <Pine.SV4.3.95.980113143614.8171B-100000@parkplace.cet.co.jp> In-Reply-To: <199801130515.XAA02963@detlev.UUCP>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 Jan 1998, Joel Ray Holveck wrote:
> >> He said static, not const. There's a difference. Static data can be
> >> modified, it's just by inference hidden from higher scopes.
>
> > Putting a const in front of a variable just makes the value read-only thru
> > that symbol.
>
> Is it not an error to change the value of a const variable through
> another symbol?
>
> const int foo = 69;
> int*bar;
> bar = &foo; /* This frequently issues a compile/lint-time warning. */
> *bar++;
>
> (And when I say "an error", I am referring to the nasal demon type of
> error, not the compiler or runtime diagnostic type of error.)
You will get a run time error if the compiler says "Umm. a literal that's
referenced by something that hangs around, let's put it here in text".
Try this uninitialized version and then try again after initializing it.
const int foo;
main()
{
int * bar;
bar = (int *) &foo;
*bar = 10;
printf("foo = %d\n", foo);
}
This is perfectly legal code. The difference in storage class also
depends on the right-hand side in this case.
I'm not advocating that you do confusing things, I just want to point out
that const isn't what it appears to be. i.e const doesn't make values
constant, it makes symbols read-only.
If you look at the signatures of common string handling functions you'll
notice that many of them declare arguments to be pointers to constant
types whereas the definition normally isn't. In this case, its usually
the intent of the author to communicate that the function won't modify the
value. It has nothing to do with the value being a constant.
Regards,
Mike Hancock
> Thanks,
> joelh
>
> --
> Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan
> Fourth law of programming:
> Anything that can go wrong wi
> sendmail: segmentation violation - core dumped
>
--
michaelh@cet.co.jp http://www.cet.co.jp
CET Inc., Daiichi Kasuya BLDG 8F 2-5-12, Higashi Shinbashi, Minato-ku,
Tokyo 105 Japan Tel: +81-3-3437-1761 Fax: +81-3-3437-1766
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.980113143614.8171B-100000>