I have this program
main()
{
char nn[10];
printf("\n Enter name: ");
scanf("%s",nn);
printf("\n%s\n",nn);
}

i compiled it with cc
when i had run it,

$./a.out

Enter name: asdfghjklpoiuyt

asdfghjklpoiuyt

it displayed morethan 10 chars... how is it possible?

That, my friend, is what is known as a "buffer overflow" and is a fine example of how NOT to code. ALWAYS check the length of your data before storing it. In this case, I would replace sscanf() with fgets(nn,9,stdin) which restricts the amount of input to what nn can hold (9 characters pluss terminting null). If you wish to capture other types of data, such as ints etc, use a combination of fgets and either atoi() or sscanf() to parse the data.

The C language itself does not do any bounds checking, and this is why C programs are so vunerable to buffer exploit attacks.

What happens when the compiler sees "char nn[10];" is that 10 bytes of memory are "reserved" to store values in but there is nothing to stop you writing as many characters as you like - your extra data just goes into the memory at the end of the 10 bytes reserved for nn, overwrting anything that was there (other variables, the stack frame, code or whatever happens to be there).

Usually this results in a core dump. You got away with in this case.

Very Very Clever and bad people can overflow a buffer in such a way that the extra data is executable code that can do pretty much anything the hacker wants. These are known as "bufer exploits" and are the subject of many many security advisaries.

thanks a lot !
I blindly believed that compiler checks the size of the array.
Oh! That's why fgets is adviced by the gurus.
Shall i ask u another question?

The COMPILER cannot do any bounds checking - it can't know at compile time that you are going to type in a very long string.

In C, arrays are really just pointers with reserved storage so for example

char nn[10]; and

char * nn; nn=malloc(10);

Are to all intents and purposes, the same thing (there are diffrences, such as the malloc'd version reserves storage from the "heap" wheras char char[] version reserves storage on the stack if it's an auto variable)

so really, the array notation is just a shorthand for defining pointers, and in C pointers are quite dumb. A pointer is little more than just a memory address. Everytime you store things at a pointer location it is your responsibilty to ensure that The address you are writing to does not belong to anything else and that there is sufficient "reserved" space that you're not going to blow anything else up. The compiler or runtime system cannot help you with that!

Pointers are the main source of difficulty with C programs, even old hands can very easily screw things up if they are not careful!

Thanks for the information.

This isn't strictly true in that
never allocates a word on the stack to hold an address. Thus you can't assign to foo like you would a pointer; this is illegal:
If you call a function with foo as an argument, the compiler does take foo's address and pass it to the function as a char*, so in that case foo does pretend to be a pointer, though it isn't really.

It should also be mentioned many many times that what you malloc() you need to free()

"This isn't strictly true in that..."


.. Which is why I said "Are to all intents and purposes, the same thing (there are diffrences...."

I used to interview candidates for trainee programmers and this was one of my tech questions....

I just didnt want to get into an in-depth tech discussion of the subtleties.

To put it simply , C starts it's counting from 0 ...... 9 , so if you declare an array of 10 chars , then you are actually declaring an array of 0 .... 10 which is 11 chars.

>>>>>you are actually declaring an array of 0 .... 10 which is 11 chars.

BZZZZZZZZT!!!!!


WRONG, WRONG and WRONG

GO STRAIGHT TO JAIL, DO NOT PASS GO, DO NOT COLLECT $200.00


char nn[10] declares an array of TEN characters, indexed from 0 to 9

I don't know much C, but I remember that strings are terminated in a \0, so would you only get 9 chars?

yes, that's correct. 10 bytes or 9 characters plus a NUL

I find it really funny when people make statements such as:

Er, have you ever written a (non-hello-world) C program that doesn't use pointers. The power of C lies in understanding pointers and the flexibility they afford. Of course, as with anything, if you don't know how to handle them, you can easily "screw up", as datprogrammer so eloquently put it. That DOES NOT make it a "difficulty".

Something that a good programmer can weild effectively, but the apprentice finds hard to use is not a "difficulty". It's a tool which needs a lot of getting used to. Experiencing the magic of pointers is what C is all about.

This is the Programming Forum. I'm amazed people just let such statements go by.

Arvind

Good comments Arvind, perhaps I should have added "a source of difficulty for novices"

Although in my 20+ years of programming, the vast majority of those " why won't this bloody program work, I've been staring at the code fo r 2 hours and it still won't work" sessions have been problems with pointers - of course it's always my dumb coding, and when I see the problem, its always something stupid and I beat myself up severly for being so dumb!

On the other hand, I've seen some crazy code from allegedly experienced programmers in my team... one example, and yes this is real code in a production system..

char x[10];

.....
x[0]=0;
x[1]=0;
x[2]=0;

etc...

aluser,

"9 characters plus a NULL"

thats assuming you're going to store a string in the character array, there's nothing to say that you have to

It could be a file buffer that you're using to process binary data from a datafile, 10 bytes at a time.