Re: [PATCH] 2.4.21-rc1: byteorder.h breaks with __STRICT_ANSI__ defined (trivial)

[Thomas Horsten <thomas@horsten.com>]

On Tuesday 06 May 2003 11:03 am, David S. Miller wrote:
> On Tue, 2003-05-06 at 02:49, Christoph Hellwig wrote:
> > > In any case, if the __STRICT_ANSI__ conditional is there in types.h, it
> > > should be there in byteorder.h as well.
> >
> > I don't agree with you in principle, but as this is 2.4 it's probably
> > better to just add it.  Would you mind sending Marcelo a patch?
>
> What if one of these "used from userland anyways" headers needs
> the 64-bit swabs?
>
> This is why I'm so against this patch.

I see where you're coming from, but not being able to compile existing applications 
where they are never used but need to include e.g. cdrom.h, is IMHO even worse.

This is doubly true since this breaks between 2.4.20 and 2.4.21 and the fix only 
touches the stuff that was actually changed (i.e. corrects the added inlines).

Another way would be to always define __u64 etc. in types.h, even if
__STRICT_ANSI__ is defined, given your argument that is maybe a better 
solution (why should the conditional be in types.h header if it's not meant
for userland in the first place).

That would also solve the problem (might break something else though, but
I don't think it's very likely esp. since a duplicate typedef would normally just 
be a warning).

So, would you prefer this:

--- linux-2.4.21-rc1-orig/include/asm-i386/types.h      2002-08-03 01:39:45.000000000 +0100
+++ linux-2.4.21-rc1-ac4-th/include/asm-i386/types.h       2003-05-06 15:07:06.000000000 +0100
@@ -17,10 +17,8 @@
 typedef __signed__ int __s32;
 typedef unsigned int __u32;

-#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 typedef __signed__ long long __s64;
 typedef unsigned long long __u64;
-#endif

 /*
  * These aren't exported outside the kernel to avoid name space clashes