[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Christian Gagneraud
Subject: Re: [gpsd-dev] [PATCH 0/5] [AIS] Modifications with potential side effects
Date: Wed, 20 Jun 2012 10:36:35 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120421 Thunderbird/12.0

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:

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).


Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Tel: + 353 (0) 1 236 5990

reply via email to

[Prev in Thread] Current Thread [Next in Thread]