enarx/flagset

Rust data types and a macro for generating enumeration-based bit flags

Enarx

This crate provides the enarx command-line tool for running applications inside Trusted Execution Environments (TEEs) using technologies such as Intel SGX and AMD SEV-SNP.

For more information about Enarx, please visit the Enarx project website.

For a quick introduction to Enarx and its goals, please see our Getting Started Guide, and for a more in-depth look please see our Technical Overview.

Using Enarx

For instructions on installing the Enarx command-line tool, please see our Quick Installation Guide.

For instructions on how to build an application that can be run within Enarx, please see our WebAssembly Guide.

Contributing to Enarx

For instructions on how to build and contribute to Enarx, please see our Contributing Guide.

For an overview of the codebase, please see our Repo Guide.

flagset's Issues

how to convert from u32 to FlagSet<enum>?

Implement cargo-audit testing for new pull requests

We'd like to enforce cargo-audit testing on all new pull requests via Travis. This should be an augmentation to the existing Travis configuration.

Test incoming pull requests for `git signoff`

We'd like commits to be signed off via git signoff, and we should test whether any signoff exists for commits on incoming PRs.

Migrate to GitHub Actions

CI is currently AWOL.

Fix clippy failure to green CI

src/lib.rs#L748
this returns a `Result<_, ()>

Out of date docs? Valueless variants *are* supported; `From<$enum> for $integer` is *not* impl'd

Hey, sweet crate by the way! Soooo glad I don't have to reinvent the wheel on this one.

Unless I'm missing something, a few statements on the flagset::flags doc page seem inaccurate.

Each enumeration value MUST have a specified value.

It looks like // Entry point for enumerations without values has existed since 0.1.0?

It is also worth noting that this macro automatically implements a variety of standard traits including:

• Copy
• Clone
  ...
• From<$enum> for $integer
  ...

From<$enum> for FlagSet<$enum> is the only macro-generated From impl I see.

It's not a huge deal to me personally (I already have bidirectional From impls for non-flag instances generated by a c-style enum bindgen-oxidation macro I'm working on). I was just really confused at the observed behavior until I cracked open the source. I imagine future devs might encounter a similar situation so I figured I'd raise awareness.

impl `From<FlagSet<F>> for F::Type`?

Obviously, from a pure-Rust standpoint, I think it makes sense to stay in the typecheck-guaranteed land of FlagSet: just think in terms of "a set of flags", and "it's a bitfield" is just an implementation detail. If you're converting to an integer, you better have a good reason.

I'm coming from the interop/FFI side of things, where I really dislike the type-looseness of winapi's "ayyy ENUM is just a bunch of constants and a type alias. Shove a STGMOVE into a VARENUM? Sure, that's allowed, actually defined, though semantically absurd. Shove a VARENUM into a STGMOVE? That's undefined, but we're not gonna stop you lmao". I can't imagine seriously going back to a language without proper sum types. The "good reason" for casting to integer, though, is "that's what the foreign API expects".

Sure, the bits method exists, but I think there's something to be said for the universally understood semantics of From/Into. Going from FlagSet<F> -> F::Type is infallible, so I can't think of a good reason off the top of my head not to impl.

[Feature]: Make FlagSet struct FFI-safe

Is there an existing issue for this?

• I have searched the existing issues

Description

Currently, the FlagSet struct doesn't have a repr attribute on it, which means it's technically not FFI-safe.

When writing an extern fn which takes a FlagSet or a struct with a FlagSet field, I get the following compiler warning:

warning: `extern` fn uses type `FlagSet<ExampleFlags>`, which is not FFI-safe
  --> src/lib.rs:16:43
   |
16 | pub extern fn do_thing_with_flags(_flags: FlagSet<ExampleFlags>) {
   |                                           ^^^^^^^^^^^^^^^^^^^^^ not FFI-safe
   |
   = help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct
   = note: this struct has unspecified layout
   = note: `#[warn(improper_ctypes_definitions)]` on by default

Here's the complete example code I used to generate that warning:

lib.rs:

use flagset::{FlagSet, flags};

flags! {
    #[repr(C)]
    pub enum ExampleFlags: u32 {
        Flag1,
        Flag2,
    }
}

#[repr(C)]
pub struct ExampleStruct {
    pub flags: FlagSet<ExampleFlags>
}

pub extern "C" fn do_thing_with_flags(_flags: FlagSet<ExampleFlags>) {
    // code here
}

pub extern "C" fn do_things_with_struct(_example_struct: ExampleStruct) {
    // code here
}

Cargo.toml:

[package]
name = "ffitest"
version = "0.1.0"
edition = "2021"

[dependencies]
flagset = "0.4.3"

Acceptance Criteria

FlagSet structs can be used in extern functions without improper_ctypes_definitions compiler warnings.

Suggestions for a technical implementation

Add #[repr(transparent)] or #[repr(C)] to the FlagSet struct. I think this would technically be considered a breaking change, although I doubt it makes any difference to the actual memory layout of a tuple struct with a single value.

Add a `cargo fmt` test to the repo

To enforce proper formatting standards across Enarx projects, we'd like to run cargo fmt on all incoming pull requests to the Flagset repo. For now, we'd like to use Travis to achieve this; an augmentation to the existing config should do it.

Implement an automated test to detect merge commits

Enarx projects should not contain merge commits, and we'd like to test incoming pull requests to ensure they do not contain any.

The best way to go about this is probably to detect whether individual commits have multiple parents. There is no simple one-line way to do this, so we'll need to implement it from scratch (probably by iterating through PR commits and analyzing them).

implement `std::error::Error` for `flagset::InvalidBits`

right now, flagset::InvalidBits, the type returned within the Err variant when creating a new flagset::FlagSet, doesn't implement std::error::Error. not only is this unorthodox for error types, but it also makes it hard to propagate errors with flagset.

it would be nice to give flagset::InvalidBits a basic std::error::Error implementation.

Is there an ergonomic way to make Flagset<T> from Vec<T>?

Hello,

I'm a Rust newbie so apologies if this is more a language question than one for your crate, but am I missing an ergonomic way of taking a vec/iterable/arr/slice of T and making it into FlagSet?

I've taken inspiration from what someone did here here and made a free function, but just wanted to know if I was missing something obvious.

There is a line here which hints why you might want to make your own container, but tbh I didn't really understand the tradeoffs. Is there something special on function APIs that means you wouldn't want to just use Flagset directly?