I believe variables are usually allocated onto the stack in reverse order. So first a 4-byte allocation for the pointer to k, then maybe a word padding (for optimization with 64-bit platforms), then ... in the first example, a 16-byte boundry for j. Then another 4- or 8-byte boundary for i. But when I say reverse-order, I mean they are "pushed" "down" the stack. But they are read "up" the stack. So that j[0] is very close to i.

This might help explain going on, as you can imagine uninitialized parts of the stack having different values depending on where in the stack they are located. Try adding a function that has an "interesting" stack and calling this new function just before your function is called. You might experience different results each time.

You have a problem in both cases. One is being caught, the other is not.
"char *i, j[15], *k" says the following:
Point to memory and call that pointer i;
Create space in memory to hold 15 characters and call that space j;
and point to memory and call that pointer k;

When you try to do "sprintf( k, "print.sh %s", i );" you are asking the computer to stick the string "print.sh ?" in the memory location you pointed to with the pointer variable k. Your problem is that you have not allocated any space to hold the string at the pointer location of k, k is currently just pointing to some random memory location and no space has been allocated to hold anything at the memory location pointed to by k.

That is the reason it dies. The reason it doensn't die (yet) in the example where j is allocated space, is that there is at least some space allocated on the stack, and k is probably accidently pointing there, and therefor corrupting j, but not causing a segv (yet).

I suggest you go study up on the differences on *k, k[10], k[10,10] and **k. When you understand what these different forms mean, you're sysadmin will have a much better day.

Thanks guys for t input.

Well n1, i was thinking on similar lines. Taking it a step further, since j was allocated 15 bytes, even if i input a buffer of say 20 (basically > 15), the program does not halt.

Now assuming tht k points to some location at/around space allocated for j, why does the above condition not cause an overflow and then cause a SEGV?

Shouldnt SEGV occur when my program accesses any memory outside its allocated space? (let alone valid/invalid addessses)

Also, i noticed tht prior to an sprintf on 'k', its value was once that of stdout, and once of the string in sprintf. So maybe these are treated as valid addresses and within program bounds?

BTW, i came up with the above scenario accidently when experimenting something. Also, i know for sure what i am doing is illegal, but perplexes me when it works!

It's an implementation detail how strict this is, some architectures may just summon up the virtual memory and add it to your working set, especially if the OS thinks you are just extending the stack.

Also different architectures are stricter than others regarding (a) writing over code areas (b) misaligned access.

Have you tried printing out the contents of 'j' when it exists? Since the introduction of 'j' is what is causing the SEGV to stop then I would guess its contents is influencing the outcome.

Everyone is so focused on 'k', I have yet to see anyone mention 'i'. The sprintf must traverse whatever contents 'i' is pointing to and emit that to 'k'. I suspect that 'j' and 'i' have more a relation than 'j' and 'k'.

If I had to take a guess, 'j' (when it exists) has, at some point, a null terminator ('\0') within it, and 'i' is (at some point before the SEGV) running into the contents of 'j'. This, of course, limits the amount of "garbage" you can both read and stick into the unreferenced 'k' and thus lessens the potential to SEGV.

Take 'j' out of the picture and the sprintf obviously runs into an area of memory it should not. My guess, while the sprintf is traversing 'i' either you overflow the heck out of 'k' because there is no null terminator in memory for quite some time or there is no null terminator before the sprintf gets into the text segment and the OS does not like it breaching the data segment.

I would test my theory, but AIX cores regardless of the presence of 'j'.

could be, but when i printed out contents of j, it was "" (obviously, as it is a dummy).
But maybe there could be some garbage in the 15 bytes allocated.
Like u mentioned, it should dump core both times.

Also, like porter mentioned it is up to the OS when/how much it should be strict.

A SEGV by definition mean, you are trying to write to a segment outside of memory allocated to you. In the first case, you had no storage allocated, only pointers, so the first write gave you the SEGV. The second one is more difficult to detect an error. As long as you are writing to ANY memory allocated to you, you won't get a SEGV. Your pointers just happen to point to allocated memory, in this case your j[] character array. Write enough stuff there, and you'll get a SEGV there also, when you fall off the end of your allocated memory. The compiler & run time libs have no idea if you want to point to allocated memory, or where in that allocated memory you want to point, with your pointers. As long as you are pointing to allocated memory, the runtime, won't issue a SEGV (You are not writing outside of allocated memory)