> 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 _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
