Date: Fri, 16 Jan 1998 11:05:00 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Joel Ray Holveck <joelh@gnu.org> Cc: atrens@nortel.ca, freebsd-hackers@FreeBSD.ORG Subject: Re: sharable static arrays? Message-ID: <Pine.SV4.3.95.980116104030.29063B-100000@parkplace.cet.co.jp> In-Reply-To: <199801151908.NAA01914@detlev.UUCP>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 15 Jan 1998, Joel Ray Holveck wrote: > 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? Storage for const defined variable isn't like a constant unless all of the following are met: 1) Is initialized. 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. 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. news:comp.lang.c might be a good place to find some real language lawyers to explain this in more detail. Regards, Mike Hancock -- "Const isn't"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.980116104030.29063B-100000>