* Endianness of particular fields? @ 2018-02-22 18:13 Guy Harris [not found] ` <83A13AAE-2089-4ED9-97D9-EDEBDD911955-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> 0 siblings, 1 reply; 3+ messages in thread From: Guy Harris @ 2018-02-22 18:13 UTC (permalink / raw) To: radiotap-sUITvd46vNxg9hUCZPvPmw http://www.radiotap.org says Important Radiotap Characteristics ... * Data is specified in little endian byte-order, all data fields including the it_version, it_len and it_present fields in the radiotap header are to be specified in little endian byte-order. This wiki has adopted the Linux convention of using __le64, __le32 and __le16 for 64-, 32- and 16-bit little endian quantities. However, for example http://www.radiotap.org/fields/dB%20TX%20attenuation.html says: Structure u16 rather than __le{anything}. I presume the *intent* is that data in particular fields always be little-endian. Part of the problem here is that the Linux convention, used to describe the comment headers specifies endianness rather than signedness (presumably everything is unsigned), and the convention used for particular fields specifies signedness rather than endianness (presumably everything is little-endian). Should the site use the {u,s}{64,32,16,8} convention uniformly, and say "all multi-byte fields in all the headers and the fields are little-endian", to make it a little clearer that fields, as well as headers, are little-endian? (Or, alternatively, say "{u,s}_le_64", "{u,s}_le_32", etc., or something similar with fewer underscores as desired?) ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <83A13AAE-2089-4ED9-97D9-EDEBDD911955-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>]
* Re: Endianness of particular fields? [not found] ` <83A13AAE-2089-4ED9-97D9-EDEBDD911955-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> @ 2018-02-22 20:19 ` Johannes Berg [not found] ` <1519330795.2637.16.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> 0 siblings, 1 reply; 3+ messages in thread From: Johannes Berg @ 2018-02-22 20:19 UTC (permalink / raw) To: Guy Harris, radiotap-sUITvd46vNxg9hUCZPvPmw On Thu, 2018-02-22 at 10:13 -0800, Guy Harris wrote: > http://www.radiotap.org > > says > > Important Radiotap Characteristics > > ... > > * Data is specified in little endian byte-order, all data > fields including the it_version, it_len and it_present fields in the > radiotap header are to be specified in little endian byte-order. This > wiki has adopted the Linux convention of using __le64, __le32 and > __le16 for 64-, 32- and 16-bit little endian quantities. > > However, for example > > http://www.radiotap.org/fields/dB%20TX%20attenuation.html > > says: > > Structure > u16 > > rather than __le{anything}. Oops. > I presume the *intent* is that data in particular fields always be > little-endian. Yes. > Part of the problem here is that the Linux convention, used to > describe the comment headers specifies endianness rather than > signedness (presumably everything is unsigned), and the convention > used for particular fields specifies signedness rather than > endianness (presumably everything is little-endian). Yeah. > Should the site use the {u,s}{64,32,16,8} convention uniformly, and > say "all multi-byte fields in all the headers and the fields are > little-endian", to make it a little clearer that fields, as well as > headers, are little-endian? (Or, alternatively, say "{u,s}_le_64", > "{u,s}_le_32", etc., or something similar with fewer underscores as > desired?) I think we should just use {u,s}{64,32,16,8} and drop the whole __le thing. I'd say we should just remove the wording about adopting the Linux convention. We'd never use __be16 or such anyway. johannes ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <1519330795.2637.16.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>]
* Re: Endianness of particular fields? [not found] ` <1519330795.2637.16.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> @ 2018-06-18 13:58 ` Johannes Berg 0 siblings, 0 replies; 3+ messages in thread From: Johannes Berg @ 2018-06-18 13:58 UTC (permalink / raw) To: Guy Harris, radiotap-sUITvd46vNxg9hUCZPvPmw On Thu, 2018-02-22 at 21:19 +0100, Johannes Berg wrote: > > I think we should just use {u,s}{64,32,16,8} and drop the whole __le > thing. > > I'd say we should just remove the wording about adopting the Linux > convention. We'd never use __be16 or such anyway. I removed it now, not sure why I forgot earlier. Sorry about that. johannes ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-06-18 13:58 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-02-22 18:13 Endianness of particular fields? Guy Harris [not found] ` <83A13AAE-2089-4ED9-97D9-EDEBDD911955-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> 2018-02-22 20:19 ` Johannes Berg [not found] ` <1519330795.2637.16.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> 2018-06-18 13:58 ` Johannes Berg
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).