[LCP]segmentation fault core dump

[Mike & Penny Novack]

"If you give a man a fish, you've fed him for a day. If you teach a man
to fish, you've fed him for a lifetime"

Mehul,
    Andrew explained perfectly well what actual mistake was made. I'd
like to take another tack, to explain how when faced with something like
this, you figure out what you are looking for.


>     ret=line_parser(values,str);
>
>     for(i=0;i<ret;i++)
>        printf("%s\n",values[ret]); /*core dump error comes here*/
>

    Initially all you know is where you got the seg fault. Well looking
at that line, you know one of two two things must be true. Either ret is
an invalid subscript or values[ret] is not the address of a null
terminated string.

    Now your function could have returned an invalid subscript.
Remember, you return -1 for error (you might want to insert explicit
code to handle that). But you also know that were ret = = -1 you would
never have executed the body of the for statement since i is never < 0.
So now you know that (however unexpectedly) values[ret] does NOT point
to (isn't the address of) a null terminated string.

    OK, there are just two ways THAT could be. Either it points to a
string that isn't terminated properly or it doesn't point to a string at
all. How to progress further depends upon whether you use debugging
tools or the old fashioned way. Quick and easy would be to insert (ahead
of the printf) an assertion that values[ret] != NULL. If the assertion
fails you know you (still) have a NULL pointer there. If you get the seg
fault again, you know the string wasn't properly terminated.  In your
case, the assertion will fail, so now you are looking to figure out how
that could have happened.

    Since this turned out to be as fundamental as the initial function
definition, I'm going to stop the analysis and address Andrew's
suggestion. It's oh too easy to get lost with levels of pointing, and
even the most experienced of us can type the wrong number of asterisks.
Worse, such mistakes are very difficult to see. Essentially Andrew is
suggesting that judgicious use of "temporary" variables may make your
code easier to read and much easier to debug. In fact, that's a pretty
big function. While it might be necessary or desirable for reasons of
efficiency to keep function call overhead to a minimum, during
"development" debugging is easier if alll functions perform more limited
processing --- you can always "unwind" some of the function calls after
initial testing.

Mike