Programming

Hi,
Please see this:
When i make a declaration as:

char *i, j[15], *k;
and then do
sprintf( k, "print.sh %s", i );

the program works fine.

But when i change the declaration to:
char *i, *k;
and then do
sprintf( k, "print.sh %s", i );
I get a segmentation fault at the 'sprintf' statement.

The program works only when j is an array of 15. Nothing less/more

Please Note: variable j is just a dummy. I do absolutely nothing with it.
Also, i know using sprintf the way i have done is illegal. The pointer is not assigned to anything, prior to such a statement.

It may be silly but could someone please explain why this happens? Guess something to do with the way memory is allocated.

Thanks in advance!

You are trying to write to random memory as "k" has not been pointed at anything. The kernel can give you three answers...

(a) let you do it

(b) trap because you are writing to read only memory, eg the program image

(c) trap because you are writing to memory that has not been allocated to you

Well, on the above lines, i could further deduce:

1. in one case, k was pointing to stdout (dont know how!), coz its memory contents were that of my printf statement, prior to the sprintf. (Surprising!)

2. In one case, k was pointing to the string part of my sprintf statement. Hence again, it is not illegal, and the program would work. (Seems possible).

However, this kind of valid but garbage initializations seem to happen only when variable j is declared. Else, the program halts by SEGV.

But i still believe that this is a special and one-off case. Guess the same code would not work on another machine. (Mine is Solaris).

Any comments/inputs/further insight anyone?

The stack that main is using won't be untouched virgin memory, it will have been used for subroutine calls by the program's prolog, ie crt0.o (or whatever) prior to main() being called.

The memory is truely in an unknown state, but I take your point about the contents being repeatable under certain conditions. I would call it a case of deja vu.

agree . However in repeated runs, the program variables are allocated the same memory location.
Even on reading in a very large string (20 chars) and sending it to sprintf, it is surprising how there is no segmentation fault.

At some point, unless 'k' is pointing to stdout, the length of the memory should cause violation, and program should get SEGV right?

Also, if at all 'k' points to stdout, on doing a flush immediately, i should see the contents of 'k' right? coz it sould overwrite previous contents of stdout.

Try and see...?

Are you running it under gdb and see where things are really going?

i'll try n post t results