RadioTap Archive on lore.kernel.org
 help / color / Atom feed
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
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?)

             reply index

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   ` 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

RadioTap Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/radiotap/0 radiotap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 radiotap radiotap/ https://lore.kernel.org/radiotap \
		radiotap@radiotap.org radiotap@archiver.kernel.org
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.netbsd.radiotap


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git