mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: torvalds@linux-foundation.org
Cc: linux-arch@vger.kernel.org, sfr@canb.auug.org.au,
	Joakim.Tjernlund@transmode.se, arnd@arndb.de,
	linux-kernel@vger.kernel.org, akpm@linux-foundation.org
Subject: [RFC][PATCH 0/4] UAPI: Fix up endianness conditionals
Date: Wed, 06 Mar 2013 20:47:25 +0000	[thread overview]
Message-ID: <20130306204724.31327.43118.stgit@warthog.procyon.org.uk> (raw)


Here are four patches to fix some of the problems with endianness-related
preprocessor conditionals I have found in the UAPI header files.

The problem is that the way that preprocessor conditionals are used to
determine endianness when building for Linux userspace (as defined by the
predominant use of glibc) is not compatible with the way that the kernel build
does things.  The problem revolves around how __BIG_ENDIAN and __LITTLE_ENDIAN
are defined in each environment.

When building for Linux userspace, __BIG_ENDIAN and __LITTLE_ENDIAN are always
defined - so the kernel's preferred:

	if defined(__xxx_ENDIAN)

is always true in userspace builds, no matter which endianness your check
employs - whereas only one is defined in the kernel builds - meaning

	#if __BYTE_ORDER == __xxx_ENDIAN

gives a warning with -Wundef if you select the undefined endianness for your
check.


Unfortunately, the UAPI header files _must_ employ the userspace variant of
these conditionals outside of __KERNEL__-conditionalised regions as these
conditionals get exposed to userspace and userspace _cannot_ be changed.

These can be fixed in the UAPI headers by changing:

	#if defined(__BIG_ENDIAN)
	#define foo 1234
	#elif defined(__LITTLE_ENDIAN)
	#define foo 4321
	#else
	#error endianness unspecified
	#endif

to:

	#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
	#define foo 1234
	#elif defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
	#define foo 4321
	#else
	#error endianness unspecified
	#endif

as it appears gcc's cpp doesn't complain about macros that aren't evaluated.

[!!!] NOTE [!!!]  These patches may adversely change the userspace API.  Since
the userspace API appears to be wrong under some circumstances due to incorrect
conditionals, it may be necessary to make an alternate fix whereby the we
select the first variant unconditionally in all cases as we would otherwise be
changing the actual userspace API.

David
---
David Howells (4):
      UAPI: Fix endianness conditionals in linux/aio_abi.h
      UAPI: Fix endianness conditionals in linux/acct.h
      UAPI: Fix endianness conditionals in linux/raid/md_p.h
      UAPI: Fix endianness conditionals in M32R's asm/stat.h


 arch/m32r/include/uapi/asm/stat.h |    4 ++--
 include/uapi/linux/acct.h         |    6 ++++--
 include/uapi/linux/aio_abi.h      |    4 ++--
 include/uapi/linux/raid/md_p.h    |    6 ++++--
 4 files changed, 12 insertions(+), 8 deletions(-)


             reply	other threads:[~2013-03-06 20:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-06 20:47 David Howells [this message]
2013-03-06 20:47 ` [PATCH 1/4] UAPI: Fix endianness conditionals in linux/aio_abi.h David Howells
2013-03-12 16:32   ` Benjamin LaHaise
2013-03-12 18:22     ` Jeff Moyer
2013-03-06 20:47 ` [PATCH 2/4] UAPI: Fix endianness conditionals in linux/acct.h David Howells
2013-03-06 20:47 ` [PATCH 3/4] UAPI: Fix endianness conditionals in linux/raid/md_p.h David Howells
2013-03-12  1:43   ` NeilBrown
2013-03-06 20:48 ` [PATCH 4/4] UAPI: Fix endianness conditionals in M32R's asm/stat.h David Howells

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=20130306204724.31327.43118.stgit@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=Joakim.Tjernlund@transmode.se \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=torvalds@linux-foundation.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

all inboxes | Powered by JetHome®