New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support bit fields for C interop #314

Open
rust-highfive opened this Issue Sep 24, 2014 · 9 comments

Comments

Projects
None yet
8 participants
@rust-highfive

rust-highfive commented Sep 24, 2014

Bitfields are commonly encountered when interacting with C code. Since many of the details of the behavior of bitfields are left to the implementation, it is hard to write cross-platform rust code that uses bitfields correctly. (Source: #1449)

Prior RFCs and other citations:

@mzabaluev

This comment has been minimized.

Show comment
Hide comment
@mzabaluev

mzabaluev Oct 14, 2014

Contributor

Wondering if there could be a Rust feature of ranges for integer types, generally useful to automatically check value domain at runtime and possible optimization hints:

let ascii: u8 match 0x00 ... 0x7F = 'a' as u8;

Then it could be reused to represent bitfields:

#[repr(C)]
struct PackedToBits {
    some_bits: u8 match 0 ... 3  // equivalent to `uint8_t some_bits: 2` in C
}
Contributor

mzabaluev commented Oct 14, 2014

Wondering if there could be a Rust feature of ranges for integer types, generally useful to automatically check value domain at runtime and possible optimization hints:

let ascii: u8 match 0x00 ... 0x7F = 'a' as u8;

Then it could be reused to represent bitfields:

#[repr(C)]
struct PackedToBits {
    some_bits: u8 match 0 ... 3  // equivalent to `uint8_t some_bits: 2` in C
}
@bgamari

This comment has been minimized.

Show comment
Hide comment
@bgamari

bgamari Oct 14, 2014

@mzabaluev in my opinion ranged integers is an orthogonal issue to bit fields which would be best treated with a combination of type-level naturals and either a macro or CTFE and custom literals,

/// An integer of a given parametrized width (less than 64 bits, of course)
struct NarrowInt<Width: int>(u64)

/// This trait would be used by the compiler to support custom literals. A macro could also be used here although this trait might provide better ergonomics.
trait FromNumber {
    /// `static` here denotes a CTFE-able function. The `Option` allows the compiler to throw an error on out-of-bound literals
    pub fn static from_number(val: i64) -> Option<Self>;
}

impl<Width> FromNumber for RangedInt<Width> {
    pub fn static from_number(val: i64) -> Option<Self> { ... }
}

bgamari commented Oct 14, 2014

@mzabaluev in my opinion ranged integers is an orthogonal issue to bit fields which would be best treated with a combination of type-level naturals and either a macro or CTFE and custom literals,

/// An integer of a given parametrized width (less than 64 bits, of course)
struct NarrowInt<Width: int>(u64)

/// This trait would be used by the compiler to support custom literals. A macro could also be used here although this trait might provide better ergonomics.
trait FromNumber {
    /// `static` here denotes a CTFE-able function. The `Option` allows the compiler to throw an error on out-of-bound literals
    pub fn static from_number(val: i64) -> Option<Self>;
}

impl<Width> FromNumber for RangedInt<Width> {
    pub fn static from_number(val: i64) -> Option<Self> { ... }
}
@mzabaluev

This comment has been minimized.

Show comment
Hide comment
@mzabaluev

mzabaluev Oct 15, 2014

Contributor

@bgamari I think ranged types could provide a superset over bit width limited types. The range might as well be parameterized, if Rust allows expression parameters for types as your example suggests.
With syntactic support, it could be possible to define more complex restrictions (using Unicode as a contrived example):

type unichar = u32 match 0 ... 0xD7FF | 0xE000 ... 0x10FFFF;
Contributor

mzabaluev commented Oct 15, 2014

@bgamari I think ranged types could provide a superset over bit width limited types. The range might as well be parameterized, if Rust allows expression parameters for types as your example suggests.
With syntactic support, it could be possible to define more complex restrictions (using Unicode as a contrived example):

type unichar = u32 match 0 ... 0xD7FF | 0xE000 ... 0x10FFFF;
@mzabaluev

This comment has been minimized.

Show comment
Hide comment
@mzabaluev

mzabaluev Nov 6, 2015

Contributor

Pulling from a forum post, the ideation to add a sub-specifier to #[repr(C)]:

#[repr(C; bitfields(foo: 2, bar: 1))]
struct A {
    foo: c_uint,
    bar: c_uint
}

As FFI should be the only application for bit fields in Rust, setting them could be considered unsafe, to punt on the implications of exceeding the range besides trimming the value to the bit width.

Contributor

mzabaluev commented Nov 6, 2015

Pulling from a forum post, the ideation to add a sub-specifier to #[repr(C)]:

#[repr(C; bitfields(foo: 2, bar: 1))]
struct A {
    foo: c_uint,
    bar: c_uint
}

As FFI should be the only application for bit fields in Rust, setting them could be considered unsafe, to punt on the implications of exceeding the range besides trimming the value to the bit width.

@graydon graydon referenced this issue Jan 6, 2016

Merged

unions #1444

@vitiral

This comment has been minimized.

Show comment
Hide comment
@vitiral

vitiral Jan 14, 2016

For general rust use, I don't understand why you couldn't just have the syntax

#[repr(pack_bool)]  // only pack the bool values
struct A {
    flag1: bool,
    flag2: bool,
    flag3: bool,
    value1: u16,
    flag4: bool,    // allowed to be out of order
    flag5: bool,
    value2: u32,
}

And the compiler would just know what to do -- packing bool (bit) values together into whatever made the most sense for the target archetecture and reading them correctly. This would be most useful for embedded platforms, but might find use outside of them as well.

For FFI layer stuff, there should be some attribute to tell the compiler the order you want things packed in, for instance:

#[repr(ordered, packed)]
struct A {
    flag1: bool,
    flag2: bool,
    flag3: bool,
    flag4: bool,    // not allowed to be out of order
    flag5: bool,
    value1: u16,
    value2: u32,
}

For repr(ordered, packed) structs, the data layout would be well defined according to a spec.

vitiral commented Jan 14, 2016

For general rust use, I don't understand why you couldn't just have the syntax

#[repr(pack_bool)]  // only pack the bool values
struct A {
    flag1: bool,
    flag2: bool,
    flag3: bool,
    value1: u16,
    flag4: bool,    // allowed to be out of order
    flag5: bool,
    value2: u32,
}

And the compiler would just know what to do -- packing bool (bit) values together into whatever made the most sense for the target archetecture and reading them correctly. This would be most useful for embedded platforms, but might find use outside of them as well.

For FFI layer stuff, there should be some attribute to tell the compiler the order you want things packed in, for instance:

#[repr(ordered, packed)]
struct A {
    flag1: bool,
    flag2: bool,
    flag3: bool,
    flag4: bool,    // not allowed to be out of order
    flag5: bool,
    value1: u16,
    value2: u32,
}

For repr(ordered, packed) structs, the data layout would be well defined according to a spec.

@vitiral

This comment has been minimized.

Show comment
Hide comment
@vitiral

vitiral Jan 14, 2016

I also don't understand why setting or reading bits in bit fields should be considered unsafe. If it follows the same structure as the rest of rust code (i.e. resides in a struct) I don't see why setting individual bits should be any more unsafe than setting bytes.

vitiral commented Jan 14, 2016

I also don't understand why setting or reading bits in bit fields should be considered unsafe. If it follows the same structure as the rest of rust code (i.e. resides in a struct) I don't see why setting individual bits should be any more unsafe than setting bytes.

@burdges

This comment has been minimized.

Show comment
Hide comment
@burdges

burdges Oct 11, 2016

Appears corrode has grown interested in this : jameysharp/corrode#75

burdges commented Oct 11, 2016

Appears corrode has grown interested in this : jameysharp/corrode#75

@retep998

This comment has been minimized.

Show comment
Hide comment
@retep998

retep998 Oct 12, 2016

Member

This is how I handle bitfields in winapi. Note that this likely won't work with non-windows platforms because only Windows has simple sane rules for bitfields.

macro_rules! BITFIELD {
    ($base:ident $field:ident: $fieldtype:ty [
        $($thing:ident $set_thing:ident[$r:expr],)+
    ]) => {
        impl $base {$(
            #[inline]
            pub fn $thing(&self) -> $fieldtype {
                let size = $crate::core::mem::size_of::<$fieldtype>() * 8;
                self.$field << (size - $r.end) >> (size - $r.end + $r.start)
            }
            #[inline]
            pub fn $set_thing(&mut self, val: $fieldtype) {
                let mask = ((1 << ($r.end - $r.start)) - 1) << $r.start;
                self.$field &= !mask;
                self.$field |= (val << $r.start) & mask;
            }
        )+}
    }
}
STRUCT!{struct WOW64_LDT_ENTRY_Bits {
    BitFields: DWORD,
}}
BITFIELD!(WOW64_LDT_ENTRY_Bits BitFields: DWORD [
    BaseMid set_BaseMid[0..8],
    Type set_Type[8..13],
    Dpl set_Dpl[13..15],
    Pres set_Pres[15..16],
    LimitHi set_LimitHi[16..20],
    Sys set_Sys[20..21],
    Reserved_0 set_Reserved_0[21..22],
    Default_Big set_Default_Big[22..23],
    Granularity set_Granularity[23..24],
    BaseHi set_BaseHi[24..32],
]);
Member

retep998 commented Oct 12, 2016

This is how I handle bitfields in winapi. Note that this likely won't work with non-windows platforms because only Windows has simple sane rules for bitfields.

macro_rules! BITFIELD {
    ($base:ident $field:ident: $fieldtype:ty [
        $($thing:ident $set_thing:ident[$r:expr],)+
    ]) => {
        impl $base {$(
            #[inline]
            pub fn $thing(&self) -> $fieldtype {
                let size = $crate::core::mem::size_of::<$fieldtype>() * 8;
                self.$field << (size - $r.end) >> (size - $r.end + $r.start)
            }
            #[inline]
            pub fn $set_thing(&mut self, val: $fieldtype) {
                let mask = ((1 << ($r.end - $r.start)) - 1) << $r.start;
                self.$field &= !mask;
                self.$field |= (val << $r.start) & mask;
            }
        )+}
    }
}
STRUCT!{struct WOW64_LDT_ENTRY_Bits {
    BitFields: DWORD,
}}
BITFIELD!(WOW64_LDT_ENTRY_Bits BitFields: DWORD [
    BaseMid set_BaseMid[0..8],
    Type set_Type[8..13],
    Dpl set_Dpl[13..15],
    Pres set_Pres[15..16],
    LimitHi set_LimitHi[16..20],
    Sys set_Sys[20..21],
    Reserved_0 set_Reserved_0[21..22],
    Default_Big set_Default_Big[22..23],
    Granularity set_Granularity[23..24],
    BaseHi set_BaseHi[24..32],
]);
@nagisa

This comment has been minimized.

Show comment
Hide comment
@nagisa

nagisa Dec 21, 2016

Contributor

A draft I had written almost a year ago would allow doing bitfields.

Contributor

nagisa commented Dec 21, 2016

A draft I had written almost a year ago would allow doing bitfields.

withoutboats pushed a commit to withoutboats/rfcs that referenced this issue Jan 15, 2017

Merge pull request #314 from Byron/master
Use single thread in `one_thread` test

@DavidDeSimone DavidDeSimone referenced this issue Jul 5, 2017

Merged

Port 'string-lessp' to Rust #217

7 of 7 tasks complete

@petrochenkov petrochenkov added the T-lang label Jan 30, 2018

@petrochenkov petrochenkov removed the A-servo label Feb 24, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment