From owner-freebsd-hackers Thu Jan 15 18:07:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA10814 for hackers-outgoing; Thu, 15 Jan 1998 18:07:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA10745 for ; Thu, 15 Jan 1998 18:06:40 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id CAA29499; Fri, 16 Jan 1998 02:05:00 GMT Date: Fri, 16 Jan 1998 11:05:00 +0900 (JST) From: Michael Hancock To: Joel Ray Holveck cc: atrens@nortel.ca, freebsd-hackers@FreeBSD.ORG Subject: Re: sharable static arrays? In-Reply-To: <199801151908.NAA01914@detlev.UUCP> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk 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"