error handling Section 1 with extra baggage

[cpb]

Found this with the G-AIRMETs at:
ftp://tgftp.nws.noaa.gov/SL.us008001/DC.avspt/DS.sgairmet/PT.bin_DF.buf/

The section 1 length in these messages is 22 octets. A normal (edition 3) section 1 is 17 bytes padded out to 18. The 17 bytes is tracked in s1.header_len, and the 18 byte length in s1.len. The s1.data_len ends up being 5 in this case.

It triggers a failure in the section 4 size calculations, which causes section 4 to have a 1 byte undersize because it uses s1.len + s1.data_len... well, s1.len = s1.header_len+1 and this never gets recalculated when the baggage is handled. 18+5 != 22...

[Yves Pelletier (yves-pelletier)]

Chris,

Would it be worthwhile to add one of these messages to the test suite?

Yves

[cpb (chris-beauregard)]

On 03/22/2012 01:57 PM, Yves Pelletier wrote:
> Chris,
>
> Would it be worthwhile to add one of these messages to the test suite?

Already done. It's just SOP. Anytime I find a bug triggered by a piece
of data, it goes into the test suite. There's also one in the MetManager
test suite. And for the most part, when I find a bug triggered by a
certain use of the API, I write/modify a test program to trigger the bug.

Having to fix a bug sucks. Having to fix a bug twice because your test
suite didn't see it come back is a whole other level of sucks.

The trick is that the decoder doesn't handle this particular message
because it claims to use Table 13, but uses descriptors which aren't
found in the Table 13 included with libecbufr. No further comment on
that particular issue ;)

However, it's okay for regression testing. The failure mode before I
fixed it was that it didn't even recognize the message as valid BUFR
because the section 4 off-by-one meant it couldn't see section 5. Now,
it can find all the sections and make sense of them even if it can't
actually display the data payload. That's fixed enough for me.

c.