Re: [gpsd-dev] [PATCH 0/5] [AIS] Modifications with potential side effects

[Christian Gagneraud]

On 20/06/12 02:53, Eric S. Raymond wrote:
> Christian Gagneraud<address@hidden>:
> > > Are these applied already?  The all look good except the change to
> > > hexdump behavior.  It's written that way for a reason - otherwise we get
> > > logfiles from NMEA devices that are unnecessarily obfuscated.
> >
> > No, nothing has been applied, I wanted your green light first.
>
> I've just merged 1, 3, and 4.  I sent you a separate note about 5.
>
> > For the hexdump, how can we move forward then?
> > Maybe we should have a wrapper function for this case, something
> > like gpsd_maybe_hexdump(), gpsd_text_or_hex_dump(), ...
> >
> > What do you think?
>
> First need to understand your testing strategy better and why you
> consider patch 2 essential to it.

Here is the test strategy:

On all the AIS data, the following tests were done:
    - AIVDM decoding
    - JSON scaled dump
    - JSON validity check on scaled dump.
    - JSON unscaled dump
    - JSON validity check on unscaled dump
    - JSON unscaled idempotency check
    - JSON unscaled/scaled idempotency check

    The last check consisted of:
    - parsing the unscaled dump
    - dumping it back in scaled mode
    - compare it with the original scaled dump.

If you consider GPSD as a black box, and look at data path using 
gpsdecode, the above will test all of them and make sure the ouputs are 
consistent:
- AIVDM -> JSON unscaled
- AIVDM -> JSON scaled
- JSON unscaled -> JSON unscaled
- JSON unscaled -> JSON scaled

> Please understand the tradeoff here.  Forcing hex dumping all the time
> may be a desirable uniformity, but it makes logs from NMEA devices
> needlessly difficult to read.

I fully understand your point. But if you try to decode these guys:
!AIVDM,1,1,,A,JB3R0GO7p>vQL8tjw0b5hqpd0706kh9d3lR2vbl0400,2*40
!AIVDM,1,1,,A,J1@@address@hidden,0*6B
!AIVDM,1,1,,B,address@hidden,0*75
!AIVDM,1,1,,A,address@hidden@370>t0Lh3P0000200H:2rN92,4*14

You will see that the hex dump contains garbage (non-ascii), which 
sounds strange to me, because it means that the values failed the "if 
(!isprint(*cp) && !isspace(*cp))" test.
Maybe it's a locale issue...

A simple way to fix the problem and make everyone happy would be to 
create a gpsd_maybe_hexdump() that contains this "printable" test and 
either returns gpsd_hexdump() or the untouched buffer.

Then the coders have the choice between a real hexdump (gpsd_hexdump) 
and a "clever" hexdump (gpsd_maybe_hexdump).

Chris

--
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/