I'm writing a Storable instance for a data type that marshals to a C structure that contains bit fields such as the following: struct Foo { short x; short y; unsigned int a : 1; unsigned int b : 1; unsigned int c : 1; unsigned int d : 1; unsigned int reserved : 12; } For the "x" and "y" fields I've been using hsc2hs and something like #{peek Foo, x} to extract the fields. However, bit fields such as "a" have me stumped. But as far as I can tell, hsc2hs doesn't support bit fields. On top of that I'm not sure I can make any safe assumptions about what order the bit fields are packed (LSB or MSB first). Have others run into this problem before? What options are there for working around it? Michael D. Adams mdmkolbe@gmail.com
Hello Michael, Friday, November 7, 2008, 8:51:46 AM, you wrote:
Have others run into this problem before? What options are there for working around it?
if your goal is to maximize portability and not speed, one option is to make another structure without bit fields, and add C helper function which converts from this intermediate structure into final one -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
* Michael D. Adams wrote:
But as far as I can tell, hsc2hs doesn't support bit fields. On top of that I'm not sure I can make any safe assumptions about what order the bit fields are packed (LSB or MSB first).
C standard allows padding and reorder of struct entries in order to match alignment requirements. The only exeption are bitfields, which must not reordered and padded. This way bit fields are the only portable way to define the binary representation in C. Unfortunly the C standard does not specify any bit order for bit fields, but almost all implementations use the machine specific bit order, in order to ease access to multiple bits wide bit field and fill LSB to MSB. But there is no guarantee. I run into this problem when writing an low level kernel interface in SPARK. The ABI (binary representation) of the kernel API depends on the C compiler flags (i.e. #pragma packed). Especially kernels of commericial unicies might generate this problem, because the developer uses gcc instead of the native compiler. The only portable way to get access to C defined structures is involving a C compiler, either using hsc or a C helper module.
C standard allows padding and reorder of struct entries
Almost. The ISO C standard does allow structs padding, but *not* reordering: http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf ISO/IEC 9899:1999 C Standard §6.7.2.1.13 "Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning." Dan Lutz Donnerhacke wrote:
* Michael D. Adams wrote:
But as far as I can tell, hsc2hs doesn't support bit fields. On top of that I'm not sure I can make any safe assumptions about what order the bit fields are packed (LSB or MSB first).
C standard allows padding and reorder of struct entries in order to match alignment requirements. The only exeption are bitfields, which must not reordered and padded. This way bit fields are the only portable way to define the binary representation in C. Unfortunly the C standard does not specify any bit order for bit fields, but almost all implementations use the machine specific bit order, in order to ease access to multiple bits wide bit field and fill LSB to MSB. But there is no guarantee.
On Fri, Nov 7, 2008 at 3:46 AM, Lutz Donnerhacke
* Michael D. Adams wrote:
But as far as I can tell, hsc2hs doesn't support bit fields. On top of that I'm not sure I can make any safe assumptions about what order the bit fields are packed (LSB or MSB first).
...
The only portable way to get access to C defined structures is involving a C compiler, either using hsc or a C helper module.
I don't think hsc2hs provides that support natively. (I would love to be proven wrong about that.) However, I think it would be reasonable to extend hsc2hs. I've attached a basic draft of an extension that would make hsc2hs support this. Basically this extra template file adds #{peek_bit <type>,<field>} and #{poke_bit <type>,<field>} which present basically the same interface as #{peek} and #{poke} but specialized with some extra smarts to support bit-fields. I probably won't have time to refine this code, but if others find this code to be useful, feel free to take and use code and maybe we can get some proper support into hsc2hs someday. *nudge nudge* Michael D. Adams adamsmd@cs.indiana.edu
"Michael D. Adams"
What options are there for working around it?
In case it's feasible, use http://www.matroska.org/technical/specs/rfc/index.html on both sides. I just can't stop to advertise that one. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.
participants (5)
-
Achim Schneider -
Bulat Ziganshin -
Dan Weston -
Lutz Donnerhacke -
Michael D. Adams