Comments (6)
And it seems like here it would be as easy as reversing the bits. But it isn't. it messes with the endianness of stored data.
from bitstring.
A uneasy hack that seems to makes these match is :
bitstring.options.lsb0 = True
reverse endianess on all Dtypes.
unpacking:
- reverse incoming data. data[::-1]
- unpack
packing:
- pack input data
- reverse byte order before sending. data[::-1]
I'm hoping there is a better way.
This doesn't really work either cause it reverses strings.
from bitstring.
Hi.
I think that pack
is working as intended here. The LSB0 mode means that reads, slices etc. are happening from right to left, so for example the reverse operation
>>> data.unpack(types)
[170, True]
is what you'd expect. When the data is unpacked here it does the right-most byte first, then the next bit. This is correct and I think it's reasonable that pack should behave in the same way.
I think there is some confusion because for this particular case reversing the byte order exactly reverses the effect of LSB0 (as both things are contained in one byte). Reversing byte order won't work in general.
Your C code is implicitly MSB0, so possibly you don't need LSB0 mode at all?
from bitstring.
Your C code is implicitly MSB0
Hmm, I'm wondering if that's correct because when I do the following:
#include <stdio.h>
#include <stdint.h>
typedef struct {
_Bool A:1;
_Bool B:1;
_Bool C:1;
_Bool D:1;
int :4;
} myTest_t;
int main()
{
myTest_t DATA = {.A=1,.B=1,.C=1,.D=1};
uint8_t Printer = *(uint8_t*)(void*)&DATA;
printf("0x%02x\n",Printer);
return 0;
}
you can check it for yourself here: https://onlinegdb.com/G4g3AkgBc
MSb0 i would expect:
0xF0
A B C D pad
LSb0 i would expect:
0x0F
```pad D C B A``
It might be that I'm misinterperting something, but this is how I'm familiar with c compilers behaving.
from bitstring.
OK, I think you're right and hopefully I get it now. The C compiler is packing the bitfields in a LSB0 manner (this is I think compiler dependent), but only the bitfields. The larger byte structures are still being packed left-to-right.
So in the original struct
typedef struct {
unsigned char Q:8;
_Bool A:1;
int :7;
} stuff_t;
the char
comes first, then the bitfields are packed LSB0 so it's the int
followed by the _Bool
. So reading left-to-right it's the first member of the struct, then the third, then the second. That's how you get the final 0xaa 0x01
output.
In bitstring with LSB0 the equivalent does the 3rd then 2nd then 1st field (reading left-to-right). For MSB0 it does it the opposite way round. So neither will match the C code.
I don't think there's anything that bitstring can do here - the packing rules of a particular C compiler are a bit out of scope. I think I would keep it in MSB0, and then try to reverse the C-packed bitfields for whichever rules the compiler has. In general a mix of bit and byte endianness!
from bitstring.
Its somewhat interesting that this hasn't shown up more often. given that pythons' own ctypes assumes the same order for little endian chips.
i actually put together something to pack and unpack these using ctypes:
its actually a python file. but it gives an example of how the packing is assumed in c python. it matches gcc. armcc. and ctypes. for x86
from bitstring.
Related Issues (20)
- 4.2.0 crashes upon import when PYTHONOPTIMIZE is set to 2 or larger HOT 2
- 4.2.0: BitArray.join() no longer ignores None types HOT 2
- Change string representation of dtypes to short version when available. HOT 1
- 4.2.x: Reading past the end of stream no longer raises ReadError HOT 2
- Significant slowdown in find / findall for some cases since version 4.1. HOT 7
- DeprecationWarning: invalid escape sequence in tests HOT 1
- Test failures due to lack of gfloat formats import HOT 2
- `BitStream.__add__` throws `AttributeError: 'Bits' object has no attribute '_pos'` HOT 3
- Add levels to dtype definitions in the dtype register HOT 1
- Add offset to Dtype
- Some exotic float codes representing negative zero converted to positive zero.
- Auto scaling rounding wrong way on occasion.
- More configurable default options for pp
- Bug initializing an Array from bytes? HOT 2
- Gfloat version requirement HOT 3
- Request full structure definition. HOT 6
- struct formats `i` and `I` not supported.
- Issue of casting f32 to e4m3mxfp HOT 5
- LSB0 Bit String Reversal is Not Reversible HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bitstring.