bits: grib_encode_unsigned_long: increment pointer, not the pointed-to value

[mkrupcale]

This fixes a long-standing (i.e. at least since 1.9.5 ca. Oct 2010) bug in grib_encode_unsigned_long where the first byte was incorrectly incremented instead of incrementing the pointer to the next byte. This would only happen if the bit position / offset was not aligned on a byte boundary (i.e. *bitp % 8 != 0), though. Fortunately, as far as I can tell, no grib_api/eccodes functions invoked grib_encode_unsigned_long such that this bug was manifested.

• src/grib_bits_any_endian.c: increment pointer, not the pointed-to-value
• src/grib_bits_ibmpow.c: likewise.

[shahramn]

Many thanks. Do you have a test case for this? (So we can show the original problem and check your contribution actually fixes it)

[mkrupcale]

No, I don't have a test case at the moment. I'm currently still trying to understand all of these low-level bit manipulation functions. In particular:

1. Why do both grib_encode_unsigned_longb and grib_encode_unsigned_long exist when they appear to do the same thing but with different implementations?
2. In contrast, the signed counterparts, grib_{decode,encode}_signed_long and grib_{decode,encode}_signed_longb appears to offer different interfaces: the variants without the b appear to take offsets and lengths in bytes, whereas those with the b take offsets and lengths in bits. Why is there this discrepancy?
3. Why are grib_get_bit and grib_set_bit reversing the bit order? That is, bitp==0 gets or sets bit 7 in the byte, while bitp==7 gets or sets bit 0. Are GRIB and BUFR BE at the bit level?
4. I have a few other related questions I posted on the ECMWF issues site[1].

I'd appreciate if you or someone else could help me understand these encoding/decoding issues so that I might try to improve it. It seems to me that the current situation is not entirely consistent and might need to be more formally specified. In particular, I think it might make sense to standardize on a LE encoding from a performance perspective these days.

[1] https://jira.ecmwf.int/browse/SUP-3097

[mkrupcale]

@shahramn Do you think you could try to answer questions 1-3 above, or should I open an issue on the ECMWF site for them? It looks like SUP-3097 has been escalated, so I suppose the developers are looking at those questions already (although I can't see the issue BUFR-65).