Date: Sat, 17 Jan 1998 02:10:46 -0600 (CST) From: Joel Ray Holveck <joelh@gnu.org> To: michaelh@cet.co.jp Cc: atrens@nortel.ca, freebsd-hackers@FreeBSD.ORG Subject: Re: sharable static arrays? Message-ID: <199801170810.CAA07800@detlev.UUCP> In-Reply-To: <Pine.SV4.3.95.980116104030.29063B-100000@parkplace.cet.co.jp> (message from Michael Hancock on Fri, 16 Jan 1998 11:05:00 %2B0900 (JST)) References: <Pine.SV4.3.95.980116104030.29063B-100000@parkplace.cet.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
>> If these were auto variables, then strategy a would require both
>> stack space for the array at runtime, and text space for the
>> initial value in the executable, whereas strategy b should only
>> require one copy of its space in either text or data, I still
>> haven't determined which. (This is still based on the assumption
>> that it is an error to modify a const variable through another
>> identifier.)
> What makes you think a const auto (strategy b) isn't on the stack?
That would probably be attributable to my making (evidently wrong)
assumptions about the language. Please note my last comment. I am
trying to, when I can semiimmediately see how, experiment with gdb to
find out what's going on.
Also note that I am, throughout this document, referring to auto const
arrays, not pointers.
> Storage for const defined variable isn't like a constant unless all of the
> following are met:
Are these three rules general for all const defined variables, or just
auto variables?
> 1) Is initialized.
Why would you have a const variable not initialized? Under what
circumstances could it be later modified, without-- through explicit
cast or function call-- casting away the const?
> 2) Is defined const.
> 3) Is scoped as an extern or is defined static regardless of scope.
> Otherwise, treat const variables as read-only symbols and the storage
> class is possibly modifiable elsewhere.
The only way I can see that it would be modifiable within a deeper
frame would be by casting away the const, and within a shallower frame
the variable does not exist (unless it was a parameter, at which case
it may or may not still be a const).
> If this were not true then our string library and a lot of other
> code would have to be overhauled. Have a look at the signatures of
> memcopy in our string library and also try other libraries such as
> glibc to see how const is used there.
Now by 'signatures', you mean that which can be inferred from
string.h, yes? For that, we would be discussing parameters.
Over the entire declaration and definition of memcpy, we do not have
any const arrays ("const int foo[32767]"), only const pointers ("const
int *foo"). Although in many respects these are handled the same, in
the case of the const pointer, the compiler has no choice about where
to put the storage.
> news:comp.lang.c might be a good place to find some real language
> lawyers to explain this in more detail.
Actually, I was hoping to find an online copy of the ANSI document, so
I can read that instead of bugging y'all. Does such a beast exist?
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801170810.CAA07800>