Thanks!

I was editing the assembly code generated by "gcc -S" and I realized that:

If I define in the main function a buffer as follows

char[8]

the first four lines in the assembly code are:

pushl %ebp
movl %esp, %ebp
subl $8, %esp
andl $-16, %esp

but if I change it by

char[9]

I get

pushl %ebp
movl %esp, %ebp
subl $24, %esp
andl $-16, %esp


and if I change it by

char[17]

I get

pushl %ebp
movl %esp, %ebp
subl $40, %esp
andl $-16, %esp

and so on.

I think the size of the stack depends on the compiler. Every 8 bytes I request, the compiler allocates 16 more.

It is right??

Please tell me if I'm being stupid!

Thank you very much for your support!

In a way, I'm getting the feeling you are on the wrong track. I mean yes, you have reached useful insights about how a particular version of a particular compiler allocates and manages memory, but if as you were saying a few posts back the driver is that you need to explain to your management why you want to fix insecure code ... I'd be looking for a different employer, or hit them over the head with Smashing the Stack for Fun and Profit by Aleph One

You are right era! I'm going to explain to my boss how to work a stack overflow bug and all its consequences.

Thanks all of you!!

Note that it's not a stack overflow bug but the fact that sprintf() does not check for bounds which causes the routine to overflow its frame.

I mean the program that I'm fixing has a buffer overflow bug, because don't validates the length of string! Thanks a lot for your support!

Let me add sth...
When some object is created say Char arr[MAX].. that is always be the part of some Segment and if the Object is occupying less than 512 bytes
Then its default segment would be of 512 bytes.So for a char arr[10] bytes we can go upto 502 bytes.That is why no segment in the case.

You are confusing disk block allocation with memory page allocation.