[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] const / static (against current CVS)
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] [PATCH] const / static (against current CVS) |
Date: |
Wed, 24 Aug 2005 14:41:44 +0100 |
User-agent: |
KMail/1.7.2 |
> 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