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
next prev parent 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.