All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stuart Brady <sdbrady@ntlworld.com>
To: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] [PATCH] include/linux/soundcard.h endian fix
Date: Mon, 23 Feb 2004 19:40:47 +0000	[thread overview]
Message-ID: <20040223194047.GA448@calypso> (raw)
In-Reply-To: <20040223122458.GA6675@tausq.org>

On Mon, Feb 23, 2004 at 04:24:58AM -0800, Randolph Chung wrote:
> > Would it be better to do the following? :
> > 
> > #ifdef(__BYTE_ORDER)
> > #  if defined(__BIG_ENDIAN)
> > #    if __BYTE_ORDER == __BIG_ENDIAN
> > #      define AFMT_S16_NE AFMT_S16_BE
> > #    endif
> > #  elif defined(__LITTLE_ENDIAN)
> > #    if __BYTE_ORDER == __LITTLE_ENDIAN
> > #      define AFMT_S16_NE AFMT_S16_LE
> > #    endif
> > #  end if
> > #endif
> 
> yes, this is much better. If you include asm/byteorder.h then this
> should always be defined. maybe add a #error to catch the (unlikely)
> case where neither is defined?

This header is used in userland - is using <asm/byteorder.h> still okay?
<endian.h> defines both __LITTLE_ENDIAN and __BIG_ENDIAN - the fact that
one of these exists means nothing - you have to look at __BYTE_ORDER.
<asm/byteorder.h> will define one but not the other, and __BYTE_ORDER is
not defined. If a user includes <endian.h> followed by <sys/soundcard.h>,
and we use <asm/byteorder.h>, then both __LITTLE_ENDIAN and __BIG_ENDIAN
will be defined at the same time. How about this? :

Index: soundcard.h
===================================================================
RCS file: /var/cvs/linux-2.4/include/linux/soundcard.h,v
retrieving revision 1.6
diff -u -r1.6 soundcard.h
--- soundcard.h	26 Jun 2003 15:08:08 -0000	1.6
+++ soundcard.h	23 Feb 2004 15:15:23 -0000
@@ -39,6 +39,13 @@
 /* In Linux we need to be prepared for cross compiling */
 #include <linux/ioctl.h>
 
+/* Endian macros. Note that they have a different meaning in the kernel.
+#ifdef __KERNEL__
+#  include <asm/byteorder.h>
+#else
+#  include <endian.h>
+#endif
+
 /*
  *	Supported card ID numbers (Should be somewhere else?)
  */
@@ -179,13 +186,28 @@
  * Some big endian/little endian handling macros
  */
 
-#if defined(_AIX) || defined(AIX) || defined(sparc) || defined(__sparc__) || defined(HPPA) || defined(PPC) || defined(__mc68000__)
-/* Big endian machines */
-#  define _PATCHKEY(id) (0xfd00|id)
-#  define AFMT_S16_NE AFMT_S16_BE
-#else
-#  define _PATCHKEY(id) ((id<<8)|0xfd)
-#  define AFMT_S16_NE AFMT_S16_LE
+#if defined(__BIG_ENDIAN)
+#  if defined(__KERNEL__) || (defined(__BYTE_ORDER) && __BYTE_ORDER == __BIG_ENDIAN)
+#    if defined(AFMT_S16_NE) || defined(_PATCHKEY)
+#      error AFMT_S16_NE (or _PATCHKEY) is already defined
+#    endif
+#    define AFMT_S16_NE AFMT_S16_BE
+#    define _PATCHKEY(id) (0xfd00|id)
+#  endif
+#endif
+
+#if defined(__LITTLE_ENDIAN)
+#  if defined(__KERNEL__) || (defined(__BYTE_ORDER) && __BYTE_ORDER == __LITTLE_ENDIAN)
+#    if defined(AFMT_S16_NE) || defined(_PATCHKEY)
+#      error AFMT_S16_NE (or _PATCHKEY) is already defined
+#    endif
+#    define AFMT_S16_NE AFMT_S16_LE
+#    define _PATCHKEY(id) ((id<<8)|0xfd)
+#  endif
+#endif
+
+#if !defined(AFMT_S16_NE)
+#  error Failed to define AFMT_S16_NE
 #endif
 
 /*

I suppose the system-specific tests aren't necessary - if you're using
our soundcard.h, then you have our <endian.h>, too. I think the #error
is a good idea for the same reason - if the #error happens, something
really is wrong, and apps might otherwise silently test for AFMT_S16_NE,
possibly even defining it themselves.

The test for AIX || _AIX strongly implies that this header was once
intended to be used on other systems. Should we just ignore that?

BTW, AFMT_S32_NE isn't defined, but it's in the specification. It might
be worth adding that. AFMT_U16_NE isn't even in the spec.
-- 
Stuart Brady

  reply	other threads:[~2004-02-23 19:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-22  7:01 [parisc-linux] [PATCH] include/linux/soundcard.h endian fix Stuart Brady
2004-02-23 12:24 ` Randolph Chung
2004-02-23 19:40   ` Stuart Brady [this message]
2004-03-07 17:32     ` Stuart Brady
2004-03-07 18:02       ` Helge Deller

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=20040223194047.GA448@calypso \
    --to=sdbrady@ntlworld.com \
    --cc=parisc-linux@lists.parisc-linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.