Skip to content
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

check bytes of repr(C) enums #15

Open
dvc94ch opened this issue Sep 27, 2021 · 12 comments
Open

check bytes of repr(C) enums #15

dvc94ch opened this issue Sep 27, 2021 · 12 comments

Comments

@dvc94ch
Copy link

dvc94ch commented Sep 27, 2021

any way to do it? I guess repr(C) is not defined on enums, although I'd hope it would generate something like this:

#[repr(C)]
struct {
    discriminant: u8, 
    variant: #[repr(C)] union,
}
@djkoloski
Copy link
Collaborator

repr(C) is actually well-defined for enums, and it lays them out as you described. Is the issue that only repr(Int) is supported? That has a slightly more efficient layout while still being C-compatible.

@dvc94ch
Copy link
Author

dvc94ch commented Sep 27, 2021

I'm trying to send archived data structures over a network and use check_archive_root to verify the bytes. I didn't realize that I only need to #[archive_attr(derive(CheckBytes))] and that that always seems to work.

@djkoloski
Copy link
Collaborator

Awesome! I'll add an enum example to the book to make it clearer.

@dvc94ch dvc94ch closed this as completed Sep 27, 2021
@dvc94ch
Copy link
Author

dvc94ch commented Sep 28, 2021

so reopening. it's still a problem when using archive(as = "Self"). although it can be worked around by not using that.

@dvc94ch dvc94ch reopened this Sep 28, 2021
@djkoloski
Copy link
Collaborator

When using #[archive(as = "Self")], you may need to use #[derive(CheckBytes)] on the enum itself instead of in an #[archive_attr(...)]. I think that as long as you have the enum set to a compatible repr, it should work. If it doesn't, I can take a closer look at it.

@dvc94ch
Copy link
Author

dvc94ch commented Sep 28, 2021

Well it's set to repr(C) but it claims it isn't

@djkoloski
Copy link
Collaborator

Hmm, this might be really dumb but do you have the #[repr(C)] before the #[derive(CheckBytes)]? The ordering can matter for determining whether some attributes get picked up.

@dvc94ch
Copy link
Author

dvc94ch commented Sep 28, 2021

Maybe I'm doing something wrong...

use bytecheck::CheckBytes;

#[derive(CheckBytes)]
#[repr(C)]
pub enum AnEnum {
    Var(u8),
    Other(u16),
}

fn main() {
    println!("Hello, world!");
}
error: archive self enums must be repr(C) or repr(Int)
 --> src/main.rs:4:8
  |
4 | #[repr(C)]
  |        ^

error: aborting due to previous error

@djkoloski
Copy link
Collaborator

Okay, I have located the issue. Thanks for your patience.

That error is outdated and inaccurate. Right now bytecheck only has support for deriving validation on repr(Int) enums, but repr(C) enums could feasibly be supported. That error message will be updated as soon as possible and I'll file an issue for adding repr(C) enum support.

@dvc94ch
Copy link
Author

dvc94ch commented Sep 28, 2021

if that's the case I'm a bit confused why this works:

use bytecheck::CheckBytes;
use rkyv::Archive;

#[derive(Archive)]
#[archive_attr(derive(CheckBytes))]
#[repr(C)]
pub enum AnEnum {
    Var(u8),
    Other(u16),
}

fn main() {
    println!("Hello, world!");
}

is ArchiveAnEnum always a repr(Int) enum?

@djkoloski
Copy link
Collaborator

djkoloski commented Sep 28, 2021

Yes, rkyv will always generate archived enums that are repr(Int) even when the original enum is repr(C).

@dvc94ch dvc94ch changed the title check bytes of regular enums check bytes of repr(C) enums Sep 28, 2021
@djkoloski djkoloski self-assigned this Sep 29, 2021
@djkoloski djkoloski removed their assignment Sep 8, 2024
@djkoloski
Copy link
Collaborator

As an update, I'm no longer planning on adding this myself since I have no need for repr(C) enums. I would not turn down a PR though!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants