> > >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
This archive was generated by hypermail 2b30 : Thu Jul 18 2002 - 10:24:11 PDT