`Pod` array semantics about bytemuck HOT 13 CLOSED

Yeah, then that's kinda dumb but also means i gotta fix the docs.

from bytemuck.

size == stride for all current rust types because size is always a multiple of alignment in current rust.

Rust could do any future change that would break a lot of people, but I'm not afraid of that happening.

particularly, since there's no stride_of, it's impossible to design around that idea.

Basically the UCG text is trying to keep open a door that's almost for sure already closed.

from bytemuck.

While it's true that this door is almost surely closed it seems nevertheless important to list it for now. Probably a short amendment of the last requirement would do. The example above needs to abuse repr(packed) to allow smuggle a repr(rust) type trough the wording of the documentation. It might just take a small clarification here.

from bytemuck.

which example with a repr rust type?

from bytemuck.

This following type would adhere to the requirements in the documentation if rust tuples would be defined to have size that is not a multiple of the alignment, which currently they could be change in the future. Let's check them one-by-one.

#[repr(packed)] // Note: *composes* with the base repr, this is not repr(C) but repr(rust)
struct Bad(u16, u8);

• The type must be inhabited (eg: no Infallible).
  Obviously true.

• The type must allow any bit pattern (eg: no bool or char, which have illegal bit patterns).
  Also true.

• The type must not contain any padding bytes, either in the middle or on the end (eg: no #[repr(C)] struct Foo(u8, u16), which has padding in the middle, and also no #[repr(C)] struct Foo(u16, u8), which has padding on the end).

  This is the assumption, that Rust might one day enable this. In the current compiler it does not occur and the struct has padding at the end. But since it is repr(rust) this is not guaranteed and if a future version would stabilize this with size 3 then this could be fulfilled.

• The type needs to have all fields also be Pod.
  Also true.

• The type needs to be repr(C), repr(transparent), or repr(packed).
  Indeed it is. I assume the documentation was intended to instead allow repr(packed) only in conjuction with one of the other base representations. However, it can be used on repr(rust), the default.

from bytemuck.

oh so packed and C,packed are different?

from bytemuck.

oh so packed and C,packed are different?

Indeed, so it seems in the documentation.

from bytemuck.

I'm not quite sure if you actually need to mention the explicit repr(C) requirement. More, since repr(transparent) relies on the representation of the underlying type one could argue that this enables the same kinds of shenanigans. Rather, I would explicitely state the stride/size requirement as above and make a sidenote that this is impossible to guarantee except by explicitly annotating the type with repr(C) or a transparent representation on top of such a type. (Apart for special exceptions such as Option<NonZeroU8> which is neither but it has the same representation as a repr(C) type so it's fine).

from bytemuck.

aside from stride/size, it must be C and not Rust because Rust allows field re-ordering

from bytemuck.

aside from stride/size, it must be C and not Rust because Rust allows field re-ordering

How are internal fields a problem to Pod? That would be the problem of the programmer applying it and using it for field initialization. But a repr-packed-rust struct is guaranteed to remain padding free even if Rust is allowed to re-order the fields.

from bytemuck.

Partly for sanity sake, if a struct has fields a and b written in that order in the source, then you cast it to an array, then arr[0] better be the a value.

But mostly I was told that it's just plain UB to, for example, cast &(u16,u16) into &[u16;2], that's just the rules. You cannot inspect or interact with the internals of repr rust except through the proscribed safe ways.

from bytemuck.

If fields were to change order, that would be very surprising (though not UB if one is very, very careful). As far as I've understood there is not even a true commitment that all instances of a particular repr-rust struct have the same order of fields? But the tuple-vs-array example, as far as I am aware, came up initially because no layout of tuples have been specified and they might still have different alignment or padding than arrays so that unconditionally casting one to the other is unsound. However, that line of reasoning is different for packed structs, which tuples are not.

But I don't want to get lost in technicalities here, it will in any case be much easier to remove some requirements than it is to add them. So, the sane option is indeed to require repr(C) for now.

from bytemuck.

Yes, Field order is fixed during compilation and all instances of a type will have the same ordering, but they don't need to match the order you see in the source code.

in other words:

struct Stuff {
  a: u8,
  b: u16,
  c: u8,
}

In this case, rustc is highly likely to move the u16 to the start or the end of the struct. And that's already more than I want to put up with as a user, even assuming it's not UB to transmute that (which it is).

from bytemuck.