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

[Martin Schlemmer <azarah@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]

On Thu, 2003-11-06 at 22:05, David S. Miller wrote:
> On Thu, 06 Nov 2003 22:09:29 +0200
> Martin Schlemmer <azarah@gentoo.org> wrote:
> 
> > On Thu, 2003-11-06 at 21:37, David S. Miller wrote:
> > > Let's say that you end up using some inline function
> > > that takes u32 arguments, and internally it uses
> > > u64 types to speed up the calculation or make it more
> > > accurate or something like that.
> > 
> > So basically only in cases where the stuff in byteorder.h
> > was not inlined ... ?
> 
> No, exactly in the cases where it _IS_ inlined.  Imagine
> this:
> 
> static inline u32 swab_foo(u32 a, u32 b)
> {
> 	u64 tmp = ((u64)a<<32) | ((u64)b);
> 	u32 retval;
> 
> 	retval = compute(tmp);
> 
> 	return retval;
> }
> 
> If that's in a kernel header somewhere, and you build with -ansi,
> you lose.

If you look at asm/types.h, u64 is kernel only namespace, so in
theory that code will not be in userspace.  Also, the whole idea
of this patch (the first one that touched byteorder.h, and not the
second that touched types.h), was to encase everything that used
__u64 that _is_ in userspace in __STRICT_ANSI__.  If there thus
was another place that did use __u64 outside a ifdef __STRICT_ANSI__,
the compile would anyhow stop with -ansi.

Your above example would thus look more like:

--
#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
static inline __u32 swab_foo(__u32 a, __u32 b)
{
	__u64 tmp = ((__u64)a<<32) | ((__u64)b);
	__u32 retval;

	retval = compute(tmp);

	return retval;
}
#else
<code without __u64>
..
#endif
--

which in theory should not have an issue.


Thanks,

-- 

Martin Schlemmer




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]