On Mon, 12 Feb 2007, Sergei Organov wrote:
> The fact remains that even GCC extensions to C can't deal with
> endianness. I'd like to have such an extension though.
It would be nice. And useful. It would also be nice if the compiler
could deal with unaligned data automatically.
Bear in mind that sometimes you don't need to convert data values from
foreign byte-ordering to native. Bitwise operations like ~, &, |, and ==
will work okay provided both operands have the same byte-ordering.
Ideally the compiler would be smart enough to understand this (and to
understand that 0 is 0 in any ordering).
> Besides, I've already said that I agree that __le16 is better than, say,
> __u16 due to the fact that it imposes more restrictions on the usage of
> corresponding fields, but having 'le' in its name doesn't help with
> endianness issues the same way having "percentage" in a type name
> doesn't help with its expected 0--100 range.
>
> What I argue against, is that "__le16 foo" is any better than "__u8
> foo_le[2]" from the POV of endianness. Or, let's put it another way,
> provided we prefer to encode endianness in the type name, why not to
> declare it like this:
>
> typedef struct { __u8 bytes[2]; } __le16_t;
>
> IMHO, this declarations express the intent of the type better than
> current declaration of __le16. It allows to correctly declare descriptor
> structures without 'packed' hackery. It avoids alignment problems.
Alignment (and packing) is a completely independent issue. It would still
be a problem even if the data value used native byte-ordering.
> It
> prevents using of variables/fields of this type as bare integers without
> resorting to GCC extensions/sparse annotations. Finally, it makes it
> obvious that your favorite:
>
> get_unaligned_le16(__le16_t const*)
>
> is indeed a good idea ;)
:-)
> I'm yet to hear single argument against the above.
1. It would prevent using bitwise operations.
2. It might prevent (depending on how clever the implementation was)
certain optimizations on little-endian CPUs.
3. It would essentially force all accesses to be treated as if they
were unaligned, even when the programmer knew they were not.
Then there's the pragmatic reason: A lot of code has already been written
and would all need to be changed over.
Alan Stern
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
