Re: [Gpsbabel-code] Invalid NMEA sentence causing Segmentation Fault

[Daniel M. <dmc...@gm...>]

A.H. (Eric) Sommer <zr...@gm...> said:
>Daniel (and those who will fix this)
>
>The '$' character is *only* at the beginning of any NMEA statement
>Thus, if it is found *anywhere* between the beginning character ('$') and
>the end of the line (CR) then the line should be considered to be faulty and
>rejected out of hand (with a nice little line to the user about a fault on
>line xxx)
>
>Cheers
>
>A.H. (Eric) Sommer

I completely agree. Your e-mail inspired me to look more closely at
that aspect of my problem and I noticed that the checksum for the
first part ($GPRMC,224803.69,A) is 24 and when xor'd with "$" (0x24)
comes to zero, so the overall checksum ends up coming out to the same
as the remainder of the sentence would be otherwise. I guess that
means my tracking device gave me a perfect storm of sorts, since if
the checksum of the RMC line had been anything but 24, the checksum
would fail and toss the line.

Even with throwing out sentences with an extra $, the problem still
seems to be there though in the sense that when I tried a line with
$GPRMC,224803.69,A*24
I got a segmentation fault. I know the sentence is malformed and
should not ever show up with a correct checksum, but you never know
what you will find a device doing, and a graceful dumping of the line
is much nicer than a segfault.

Would others agree that we should dump lines with more than one "$"?
If it seems to be something agreeable to everyone, I can try my hand
at making a patch to do it and another to prevent the segfault. I
can't find a copy of the actual NMEA standard, so I can't confirm that
the $ is never used other than the start, but I don't think I have
seen it in "normal" sentences. I did see it in the middle of some
$GPAPB sentences, but that may be a weird Magellan quirk.

Sorry for the long messages.

Thank you,
    Daniel McAllaster