viq wrote:
On Saturday 03 December 2005 22:13, Miod Vallat wrote:
...ok, now i don't know what to think of it. The described behaviour was
observed on a Fedora Core 4 system (gcc 4, IIRC) - and right now i tried
it on a different linux system, with gcc 3.4 installed - and it works
fine there as well, with [9] set. Any idea what's causing this?
The compiler in OpenBSD will reorder local variables. In your case,
``type'' is below ``perms'' (unlike the Linux compiler), and due to
alignment, you can be lucky enough to overflow perms a bit without this
causing problems.
Miod
Makes sense, I guess. But shouldn't the new memory protection stuff disallow
even that little bit?
nope, the new "memory protection stuff" (c) does not deal with that :-)
local variables are allocated on the stack while the new memory
protection stuff (c) ensures that heap
allocated memory is used in a sane way.
man alloca, man brk (sbrk), man malloc, man mmap
as the man pages explain, some of these are not to be used anymore, but
they can help you google
for more information on how things work and particularly what is the
difference between local
variables and dynamically allocated memory.
++ veins
nb. the new memory protection stuff (c) helped me spot bugs in code that
ran "perfectly" for years on
all kind of systems/architectures. As soon as i ran a project
linked with my
"working-in-a-so-wonderful-way" lib on an OpenBSD 3.8, a segfault
occurred and caused me to fix
some use-after-free's that i would have never found by reading the
code. /me is amazed and just can't
get over it ;-)
