So am I right that bitfield widths would first need to be added to the rust struct definition and code generator before they can be added to bindgen? I poked around the AST and middle code a bit but couldn't find it if it was there.
martin On Sun, Sep 8, 2013 at 12:36 PM, Matthieu Monrocq <[email protected]> wrote: > I was using the C++11 Standard actually, but I spoke from memory. Consulting > n3485 9.6 [class.bit] it is indeed less clear-cut than I thought. > > 1/ [...] The value of the integral constant expression may be larger than > the number of bits in the > object representation (3.9) of the bit-field’s type; in such cases the extra > bits are used as padding bits and > do not participate in the value representation (3.9) of the bit-field. [...] > > Seems to indicate that the type used for the bit-field does matter. That is > if the underlying type is too narrow, then the representable range of values > is cropped. > > However it continue thusly: > > 1/ [...] Bit-fields are packed into some addressable allocation unit. [ > Note: Bit-fields straddle allocation units on some machines and not on > others. [...] > > Unfortunately it is unclear, now that I read back, what "allocation unit" > truly means. I searched in gcc documentation and even them defer the > decision to the ABI [1] > > > In any case, given that: > > 1/ [...] Allocation of bit-fields within a class object is > implementation-defined. Alignment of bit-fields is implementation-defined. > [...] > > and > > 1/ [...] Bit-fields are assigned right-to-left on some machines, > left-to-right on others. [...] > > So it appears that one would really need to check the ABI even for the least > properties of bit-fields. > > > -- Matthieu > > [1]: > http://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit_002dfields-implementation.html > > > > On Sun, Sep 8, 2013 at 7:50 PM, Corey Richardson <[email protected]> wrote: >> >> On Sun, Sep 8, 2013 at 1:49 PM, Matthieu Monrocq >> <[email protected]> wrote: >>> >>> Actually, for bitfields the types into which the bits are packed are not >>> left to the compiler. If you said "int c : 4", then it will use a "int". >>> >>> If you have: >>> >>> int a : 24; >>> int b : 24; >>> int c : 16; >>> >>> and int is 32 bits on your platform, then a will be 24 somewhere in 32 >>> bits, same thing for b, and c will be 16 bits somewhere in 32 bits; for a >>> single bit field cannot be split among several underlying integers. >>> >> >> I didn't get that understanding from my reading of the C11 standard; which >> standard and section says this? I could have misunderstood. > > _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
