E0587 error on packed and aligned structures from C #59154
Comments
jonas-schievink
added
A-diagnostics
|
The error message could be improved to say why these hints are incompatible (that is, if this error shouldn't be removed outright) |
pnkfelix
added
the
T-compiler
|
Note that the aligned outer/packed inner workaround is still really limited. If the struct contains any struct fields with their own alignment, then you'll still hit this error. (The So I think it makes sense for rust to support this for repr C/FFI purposes at the very least. |
|
note that |
|
Having structs with #[repr(C, align(4))]
struct Foo(u8);
#[repr(C, packed(1))]
struct Bar(Foo);What is |
Actually no, gcc can do whatever it want even targeting windows, the "only" requirement is that the final program work. Also, a structure defined in user side can only be use by user side, so gcc don't have to follow msvc rule to work on window in the user side. OFC, when gcc need to call Windows API they need to follow their rules, also note I don't talk about msvc rules but those of Windows API (they have probably the same anyway). All of this to say, C ABI is not a standard thing, |
If MinGW compiled binaries want to do anything they have to be able to call into dlls compiled by VC++, which means they have to match the ABI that VC++ uses. Whether the C ABI is standardized or whether the language features in question are even standard is irrelevant. If there is a dll out there that uses Having |
retep998
added
the
T-lang
|
Yes, but all of this is implemented side, C doesn't care of all of that, dll is not a thing in C standard, if MinGW want to handle dll produce by VC++ is their problem not C problem. I disagree about Rust trying to bet about what all C compiler should produce to have a FFI interface. C is design to be very flexible on what a compiler can do. So you are hurting a wall. Unless you want something like The "best guess" is already a very good thing to have in the Rust side. I find that Rust don't have the ressource to handle every case of every implementation of C (specially with Microsoft, MSVC is not a true C compiler) |
What is or isn't a "true" C compiler is not important nor is it relevant. Rust needs to be able to interface with system libraries, which means that Rust needs to match the ABI used by system libraries. Therefore on Windows Rust has to match the VC++ ABI because that is the ABI used by system libraries. If MinGW differs from this then Rust is in a tight spot because In my opinion, having the behavior of mixing |
|
What if |
|
On the contrary I think Windows is the common use case and |
|
I'm not sure why you think Windows is necessarily the common case? The initial example above is from the Linux kernel headers and is blocking development of Rust kernel modules that use that and other similar structs. We need some way of being ABI compatible with the Linux kernel for the same reason that we need to be ABI compatible with VC++ libraries. |
For the same reason that some people think non-Windows is the common case. More seriously, I am opposed to implementing either behavior until the lang team decides on a solution that allows both behaviors to be used. I want this to be resolved just as much as you do, but I'm not willing to throw some platforms under the bus for the sake of other platforms. |
|
I think the point was that there is only an ABI ambiguity on Windows and the ABI behaviour doesn't necessarily need to be consistent across platforms. Defining the same semantics for packed+aligned on both All that said, though, it sounds like we do need to start an RFC on defining a syntax for controlling layout for the combination of packed structs and aligned fields. |
|
We discussed this on Discord, and here's a rough sketch of some ideas and next steps:
|
crlf0710
added
the
C-enhancement
|
Did anyone talk to the MinGW and/or GCC people about the ABI issue yet? If so, links to relevant conversations would be good. |
…nner packed struct, as Rust doesn't allow packed and aligned types (see rust-lang/rust#59154).
…uct (#233) Align by aligning a wrapper struct around an inner packed struct, as Rust doesn't allow packed and aligned types (see rust-lang/rust#59154).
|
We've been discussing this issue in the bcachefs IRC recently because it's become a blocker for continuing to integrate Rust more into bcachefs. It seems like the thing holding it back is the difference in behavior between platforms. From the example given it seems like the difference comes down to whose alignment wins when you have a parent/outer struct with an embedded child struct. One compiler uses the child struct's alignment, the other the parent. One idea we discussed: what about creating a version of the
The exact names don't matter at this point--just that we can come up with something reasonable to move forward. I'd appreciate feedback on this idea. Also, I take it this will require an RFC at some point to either introduce a new attribute, or change the behavior of the current attributes? I am willing to try to get that started by initiating a pre-RFC discussion, if that'd be helpful. |
They should hit a different error, no? "packed type cannot transitively contain a @bertschingert @ojeda does bcachefs/Rust-for-Linux need #59154 or #100743? |
When converting C structures that are both packed and aligned using either C2Rust or bindgen, such as:
the code that either tool produces looks something like:
This Rust code fails to compile due to error
E0587:We can work around this in C2Rust by emitting an aligned outer/packed inner structure pair (I think bindgen could do the same), but I'm wondering if it would be better to fix this on the Rust language/compiler side.
The text was updated successfully, but these errors were encountered: