On Mon, 25 Jan 2021 22:11:35 +0100 (CET) Justin Iurman wrote: > >>> If you meant the old/current one, well, I don't understand why the big > >>> endian definition would look like this: > >>> > >>> #elif defined(__BIG_ENDIAN_BITFIELD) > >>> __u32 reserved:20, > >>> pad:4, > >>> cmpri:4, > >>> cmpre:4; > >>> > >>> When the RFC defines the header as follows: > >>> > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | CmprI | CmprE | Pad | Reserved | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> > >>> The little endian definition looks fine. But, when it comes to big > >>> endian, you define fields as you see them on the wire with the same > >>> order, right? So the current big endian definition makes no sense. It > >>> looks like it was a wrong mix with the little endian conversion. > > > > Well, you don't list the bit positions in the quote from the RFC, and > > I'm not familiar with the IETF parlor. I'm only > > Indeed, sorry for that. Bit positions are available if you follow the link to > the RFC I referenced in the patch. It is always defined as network byte order > by default (=BE). > > > comparing the LE > > definition with the BE. If you claim the BE is wrong, then the LE is > > wrong, too. > > Actually, no, it’s not. If you have a look at the header definition from the > RFC, you can see that the LE is correct (valid translation from BE, the *new* > BE in this patch).
Sigh, I see it now. Thanks!
