Re: Smashing the Stack?
From: Dan Kaminsky (dan@doxpara.com)Date: 07/18/02
- Previous message: Wolf, Glenn: "RE: SQL Injection Legalities"
- In reply to: fila: "Re: Smashing the Stack?"
- Next in thread: Gigi Sullivan: "Re: Smashing the Stack?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 18 Jul 2002 10:29:13 -0700 From: Dan Kaminsky <dan@doxpara.com> To: fila <fila@detack.de>
>
>
>the real question is how did the gcc developers come to this solution ?
>I mean ... it looks pretty stupid. for a 3 chars buffer the compiler
>alocates 24 bytes and for a 4 chars buff only 4 bytes ?!?!?!
>the same problem you encounter if you go further with your exploration:
>for a 7 chars buff -> 24 bytes
>for a 8 chars buff -> 8 bytes :)))))))))))
>
>isn't it dumb ? it's been allready a pretty long time since I keep
>looking for somebody to explain why does the gcc alocate space in this
>manner.
>
>
>
4 chars = 4 bytes = 32 bits
8 chars = 8 bytes = 64 bits
Unsurprisingly, it looks like GCC is trying to be more efficient when
operating on variables or structures that align across 2^n (hardware
boundries / programmer fetish). My guess, completely pulled out of my
ass, is that non-2^n stuff is thrown on the stack inline with all
metadata, while 2^n stuff has all the metadata piled on in the beginning
with pointers to actual data. So to read a bunch of vars, you just do a
mass copy, instead of repeatedly skipping around.
I don't do much with stacksmashing, but that's what I assume is going on.
--Dan
- Previous message: Wolf, Glenn: "RE: SQL Injection Legalities"
- In reply to: fila: "Re: Smashing the Stack?"
- Next in thread: Gigi Sullivan: "Re: Smashing the Stack?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|