From: Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
To: radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org
Subject: Endianness of particular fields?
Date: Thu, 22 Feb 2018 10:13:32 -0800 [thread overview]
Message-ID: <83A13AAE-2089-4ED9-97D9-EDEBDD911955@alum.mit.edu> (raw)
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?)
next reply other threads:[~2018-02-22 18:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-22 18:13 Guy Harris [this message]
[not found] ` <83A13AAE-2089-4ED9-97D9-EDEBDD911955-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2018-02-22 20:19 ` Endianness of particular fields? Johannes Berg
[not found] ` <1519330795.2637.16.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-06-18 13:58 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83A13AAE-2089-4ED9-97D9-EDEBDD911955@alum.mit.edu \
--to=guy-frubxkncsvf2fbvcvol8/a@public.gmane.org \
--cc=radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).