Alan Stern <[EMAIL PROTECTED]> writes:
> On Fri, 9 Feb 2007, Sergei Organov wrote:
>
>> Alan Stern <[EMAIL PROTECTED]> writes:
>>
>> > On Thu, 8 Feb 2007, Sergei Organov wrote:
>> >
>> >> IMHO aligned(N) should be used in portable code only to *increase*
>> >> alignment (this effectively excludes usage of 'packed'), and then the
>> >> alignment won't affect the low-level operations, that automatically
>> >> answers your question. Simple?
>> >
>> > If you don't consider the alignment attribute to be part of the type, then
>> > you can indeed express "16-bit-little-endian-unsigned-integer-unaligned"
>> > as a C type. In fact __le16 expresses it perfectly all except for the
>> > "unaligned" part, which you agree doesn't belong in the type.
>>
>> How does it express the little-endian part? Just by the 'le' in its
>> name? I'd like a variable of type __le16 to be converted to native
>> endianness when assigned to, say, an int variable (and vise
>> versa). Besides, the 'bitwise' tricks are not C, so if we stay in C, the
>> __le16 is basically something like 'unsigned short' that does not express
>> more than '16-bit-unsigned-integer'.
>
> If you remain within the confines of C, it's impossible to express most
> types. As a simple example, consider a variable that stores an integer
> percentage value: a number between 0 and 100. There's no way to express
> that as a type in C.
Sure, and therefore, if one needs to express it, he will create an
opaque struct and a set of routines to deal with it, right? That's what
I basically suggested for a
"16-bit-little-endian-unsigned-integer-unaligned".
> The fact is, the Linux kernel is expressly designed to use the GCC
> extensions to C (and even more, the sparse annotations). This allows you
> to express more concepts in the type, even if it still isn't as much as
> you might like. The notation even allows you to express concepts that can
> be understood by a human reader, although not by the compiler.
The fact remains that even GCC extensions to C can't deal with
endianness. I'd like to have such an extension though.
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. 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.
> If you insist that all the important information in a program be
> expressed in a form the compiler can understand,
Yes, for the information that affects program behavior I don't see any
other way than to explain it to the compiler. For auxiliary information
comments and naming conventions are OK.
> does that mean you also refuse to use comments?
No. What I refuse to accept is creating a problem first, and then adding
comments to help others deal with the problem.
-- Sergei.
-------------------------------------------------------------------------
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
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
