From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1E7vxy-0000Rt-R3 for qemu-devel@nongnu.org; Wed, 24 Aug 2005 10:10:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1E7vxx-0000RY-67 for qemu-devel@nongnu.org; Wed, 24 Aug 2005 10:10:58 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1E7vu3-0008Jb-LF for qemu-devel@nongnu.org; Wed, 24 Aug 2005 10:06:55 -0400 Received: from [65.74.133.11] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1E7vWs-0000Pu-23 for qemu-devel@nongnu.org; Wed, 24 Aug 2005 09:42:58 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] const / static (against current CVS) Date: Wed, 24 Aug 2005 14:41:44 +0100 References: <20050823174026.GA27203@rhlx01.fht-esslingen.de> <23bcb8700508240554653c7ff0@mail.gmail.com> In-Reply-To: <23bcb8700508240554653c7ff0@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508241441.45656.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org > Probably more important is to make sure none constant data structures > are done on the stack. There is no good reason why any code page > should be read-write. Huh? this is nonsense. You have three segements in an application (ignoring dynamic heap allocated memory): The RO segment that contains code and readonly data. This is typically implemented as a readonly file mapping shared by multiple applications. The RW segment contains read/write data, some of which may be initialized by data stored in the executable file, the rest is zero-initialized at startup. The Stack is readwrite, unititialized, and typically allocated dynamically at runtime. The compiler never puts readwrite objects in th RO segment. If it does you've got a buggy toolchain or build system. Making global data readonly is a small win because it means it can be shared by multiple instances of the same application. Moving global RW data onto the stack isn't neccly a win. Most systems have a relatively small limit on stack size, so putting large objects on the stack is a bad idea. Contrary to popular belief the "const" qualifier on pointers has absolutely no effect on optimization. It's simply a debugging aid so the compiler will generate an error if you accidentally assign to it. It's perfectly legal to cast a (const char *) to a (char *) then dereference and write to it, provided the object the object it points to is modifiable. Paul