c_void should not be an enum with public variants

[steveklabnik]

originally filed as rust-lang/rust#20274

[geofft]

I don't think there's another approach - @tomjakubowski suggested #[repr(u8)] struct on the original bug, but unfortunately that's not valid syntax. And as soon as I add so much as a () member to one of the enums, it ceases to really be a u8 as far as LLVM's optimizations are concerned, although it's still size 1. (Hm, this seems vaguely like a bug.) Try playing around with this sample on rust.godbolt.org.

That said, I don't think this is a problem: it isn't memory-unsafe to be able to construct a c_void, so I don't think libc needs to do anything about this. If you go and say let x = c_void::__variant1, it's pretty clear you're doing something silly. But there's nothing that takes a c_void itself, or a &c_void or anything.; everything just takes *mut c_void or *const c_void, and you're already allowed to just cast any pointer to. I can't think of a way in which the existence of that variable x causes problems. So probably it's best to leave it like it is.

(It is more of a problem for libraries which are using the same trick to represent an opaque struct, i.e., what C means by struct foo; in a header file. If the C library wants you to call a constructor function to get a pointer to something, you shouldn't be able to just generate a member of that type. But for c_void, that's not a concern. And I'd argue that those libraries don't need or want the malloc/free optimization.)

[dtolnay]

In my opinion there is no reason to change this. The implementation of c_void is just trivia for compiler experts and has no practical consequence.

If other people feel strongly that a struct is more appropriate, I think it is now possible with rust-lang/rust#43036:

#[repr(transparent)]
pub struct c_void(Void);

#[repr(u8)]
enum Void {
    Irrelevant,
    Likewise,
}

[gnzlbg]

@dtolnay IIRC this should just be:

extern {
    type c_void;
}

but I might be misunderstanding what extern types were introduced for (I did not follow the RFC discussion about that back then).

[gnzlbg]

Anyways any change in this direction should be done together with other breaking changes, so maybe one should label this as "worth experimenting with it for the 0.3 release" (not that a 0.3 release will ever happen until the whole ctypes situation progresses anyways).

[gnzlbg]

libc now just re-exports core::ffi::c_void