Open vsouvan opened 4 years ago
(by yves-pelletier) Chris,
Would it be worthwhile to add one of these messages to the test suite?
Yves
(by 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.
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...
Imported from Launchpad using lp2gh.