From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] const / static (against current CVS)
Date: Wed, 24 Aug 2005 14:41:44 +0100 [thread overview]
Message-ID: <200508241441.45656.paul@codesourcery.com> (raw)
In-Reply-To: <23bcb8700508240554653c7ff0@mail.gmail.com>
> 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
next prev parent reply other threads:[~2005-08-24 14:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-23 17:40 [Qemu-devel] [PATCH] const / static (against current CVS) Andreas Mohr
2005-08-24 3:24 ` Mulyadi Santosa
2005-08-24 12:54 ` Doctor Bill
2005-08-24 13:41 ` Paul Brook [this message]
2005-08-24 14:38 ` Andreas Mohr
2005-08-24 14:49 ` Paul Brook
2005-08-24 16:49 ` Doctor Bill
2005-08-24 20:35 ` Jamie Lokier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200508241441.45656.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.