decoder broken for all BUFR message edition 4 when section 1 length is 23

Bug #1284660 reported by vanh souvanlasy
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libECBUFR
Fix Committed
Critical
vanh souvanlasy

Bug Description

The decoder failing on all valid BUFR messages edition 4 where section 1 length is exactly 23 bytes, which correspond to specification.
The decoder seems to be expecting a padding bytes which is not always there. As a result, failed to decode several valid message.
which tested as OK using the BUFR checker.

Revision history for this message
vanh souvanlasy (vanh-souvanlasy) wrote :
Changed in libecbufr:
importance: Undecided → Critical
Revision history for this message
vanh souvanlasy (vanh-souvanlasy) wrote :

This seems to affect the decoder since version 0.8.4

Revision history for this message
Yves Pelletier (yves-pelletier) wrote :

Vanh, thank you for the verbal briefing on this bug. My general comment would be that when decoding section 1, the value specified in octets 1-3 is the only "correct" value for the length of section 1. In a correctly encoded BUFR message, the total number of octets in section 1 must match the length given. A message that does not meet this condition is malformed and should trigger an error condition. And finally, there is no requirement for section 1 to be of even length.

Changed in libecbufr:
status: New → Confirmed
assignee: nobody → vanh souvanlasy (vanh-souvanlasy)
status: Confirmed → In Progress
Changed in libecbufr:
status: In Progress → Fix Committed
Revision history for this message
cpb (chris-beauregard) wrote :

> And finally, there is no requirement for section 1 to be of even length.

Not in edition 4.

Regulation 94.1.3 (requiring that all sections are even length) still applies for edition 2 and 3.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.