• noobi <noobi_member pathlink.com> Aug 29 2003
• Jan Knepper <usenet digitalmars.com> Aug 29 2003
• "KarL" <someone somewhere.org> Aug 31 2003
• Heinz Saathoff <hsaat bre.ipnet.de> Sep 01 2003
• "KarL" <someone somewhere.org> Sep 01 2003

noobi <noobi_member pathlink.com> writes:

#include <stdio.h>

main()
{
char ar[9];

ar[10] ='T';
printf("%c",ar[10]);

}

Output > T
Why I got "T" in output and not an error ?

Jan Knepper <usenet digitalmars.com> writes:

Because that's exactly what you asked the program to do.
You created an array bounds violation. C does not care about that. It 
just means you are accessing memory that you have not declared.

Jan



noobi wrote:
 #include <stdio.h>
 
 main()
 {
 char ar[9];
 
 ar[10] ='T';
 printf("%c",ar[10]);
 
 }
 
 Output > T
 Why I got "T" in output and not an error ?
 
 

"KarL" <someone somewhere.org> writes:

In addition, you are only using a small amount of stack for the array
and the stack grows upwards (or downwards depending on your
point of view)  for the character array and hasn't hit the "roof".
Printf happens to be a varargs and therefore the array argument
is on top of stack.

if you include this:

extern "C" unsigned __cdecl _stack = 32; // or some smaller number
// which I haven't tried to see which causes failures

You might get a crash.

If you read the news lately, this is exactly the scenerio of what we called
the buffer overflow. Your "buffer" of 9 character is "overflowed".  Attacker
can use these sort of programmer's flaw to do something nasty

"Jan Knepper" <usenet digitalmars.com> wrote in message
news:biov51$sl7$1 digitaldaemon.com...
 Because that's exactly what you asked the program to do.
 You created an array bounds violation. C does not care about that. It
 just means you are accessing memory that you have not declared.

 Jan



 noobi wrote:
 #include <stdio.h>

 main()
 {
 char ar[9];

 ar[10] ='T';
 printf("%c",ar[10]);

 }

 Output > T
 Why I got "T" in output and not an error ?

Heinz Saathoff <hsaat bre.ipnet.de> writes:

KarL schrieb...
 n addition, you are only using a small amount of stack for the array
 and the stack grows upwards (or downwards depending on your
 point of view)  for the character array and hasn't hit the "roof".
 Printf happens to be a varargs and therefore the array argument
 is on top of stack.
 
 if you include this:
 
 extern "C" unsigned __cdecl _stack = 32; // or some smaller number
 // which I haven't tried to see which causes failures
 
 You might get a crash.


I would assume a crash when main returns. Writing beyond the limit can 
overwrite the return address for main. It doesn't do here because dm 
allocates 12 byte of stack space here (padding for dword alignment?). 
With optimization the array isn't allocated at all and 'T' is directly 
pushed as a argument to printf.

- Heinz

"KarL" <someone somewhere.org> writes:

See sample:

http://www.securiteam.com/securityreviews/5OP0B006UQ.html


"Heinz Saathoff" <hsaat bre.ipnet.de> wrote in message
news:MPG.19bd2bc5421c07909896d1 news.digitalmars.com...
 KarL schrieb...
 n addition, you are only using a small amount of stack for the array
 and the stack grows upwards (or downwards depending on your
 point of view)  for the character array and hasn't hit the "roof".
 Printf happens to be a varargs and therefore the array argument
 is on top of stack.

 if you include this:

 extern "C" unsigned __cdecl _stack = 32; // or some smaller number
 // which I haven't tried to see which causes failures

 You might get a crash.


 I would assume a crash when main returns. Writing beyond the limit can
 overwrite the return address for main. It doesn't do here because dm
 allocates 12 byte of stack space here (padding for dword alignment?).
 With optimization the array isn't allocated at all and 'T' is directly
 pushed as a argument to printf.

 - Heinz