Mail Archives: djgpp/2013/06/21/18:15:14
On Tuesday, June 18, 2013 6:32:07 PM UTC-7, Rod Pemberton wrote:
> "K.J.Williams" <lordwilliams1972 AT gmail DOT com> wrote in message
>
> Did you run DJGPP's symify on the crash output?
>
>
>
> I assumed that symyify was how you knew strtok() with a NULL
>
> pointer was the issue.
>
>
>
> Symify will convert the call frame numbers to named function
>
> calls.
>
Thats how I discovered the error... I was not understanding what
kind of error message I was getting , until - I had to do some
hard thinking about the problem.
>
>
> > So I wrote the parstext.c to test string_parser() and it worked
>
> > after I compiled it with DJGPP - but when I implemented
>
> > string_parser in my bigger program which has many files that are
>
> > thousands of lines, I get a segmentation fault ( the general
>
> > protection fault warning by the compiler in this case ) for
>
> > allowing strtok() to return a NULL pointer as a error which is
>
> > copied to the string that gets passed to the calling statement
>
> > in my large program, that I was not checking for - because I
>
> > didn't know that I should have in the first place. But more
>
> > importantly a bad implementation use of strtok().
>
> >
>
> > But it doesn't make sense to me that the general protection
>
> > fault warning doesn't happen with string_parser() in
>
> > parstext.c - which would have really helped me alot.
>
> > Thats why I am confused
>
> > ....
>
>
>
> Personally, I have a little bit of a problem identifying C coding
>
> errors in *other* people's code. Those on comp.lang.c are good
>
> for that, if they're good for anything. It was a hostile group
>
> the last time I was there... I tend to code in a subset of C
>
> which reduces certain C errors. Since we can't test WATT, we can
>
> only guess as to the error based on your descriptions. My guess
>
> is the actual crash problem is in WATT somewhere and not
>
> parsetext.c. I.e., it seems that the code in parsetext.c is not
>
> being misused in the exact same way. Of course, I haven't gone
>
> through your parsetext.c in detail. So, it could be parsetext.c
>
> has the same error, but it is just not triggering the same error.
>
string_parser(); was copied directly into one of the source code scripts
in my project that I use to compile that creates WATT.
>
> If you haven't run symify on WATT's crash output, do so. It
This was done..
>
> Go through them in order too. I.e., the
>
> first error or warning should be fixed first, second one second,
>
> ... Errors and warnings can cascade causing others, i.e., the
>
> first few are real but later ones aren't real.
>
That's how I usually fix my programming from errors - the first error
in a list of errors, shows a domino effect with other pieces of code.
>
>
>
> Rod Pemberton
KJW
- Raw text -