You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In working with BUFR data from SIO Lagrangian Drifter Lab, I found some data where nbits=38 which caused an IndexError in this section of bitops.py as the number of bits only goes up to 32:
To fix this, I'd like to submit a pull request that will raise the valid nbits to 64 as a quick fix in constants.py. As a more robust option, is it worth replacing this with a function that can handle the higher options (and perhaps use the constant for quick computation of the value)? something like
I am not aware of any numeric entry takes more than 32 bits. It's possible in theory (the spec does not seem to forbid it). But I haven't seen one in practice. Do you mind share the descriptor of this element? Is it from a local table?
Having it checked dynamically as you suggested can be useful. This plus your PR #21 that bumps it to handle 64 bit should give enough coverage.
PS: this may be a typo in your code snippet, but it should be
In working with BUFR data from SIO Lagrangian Drifter Lab, I found some data where nbits=38 which caused an IndexError in this section of bitops.py as the number of bits only goes up to 32:
To fix this, I'd like to submit a pull request that will raise the valid nbits to 64 as a quick fix in constants.py. As a more robust option, is it worth replacing this with a function that can handle the higher options (and perhaps use the constant for quick computation of the value)? something like
If so, I can work on a patch for that too.
The text was updated successfully, but these errors were encountered: