2.4.21-rc1: byteorder.h breaks with __STRICT_ANSI__ defined (trivial)

Quoted 1 line · Thomas Horsten

The following patch fixes the problem:

Making the u64 swabbing functions unavailable is not an acceptable solution.

Quoted 6 lines · David S. Miller

Quoted 1 line · Thomas Horsten

The following patch fixes the problem:

Making the u64 swabbing functions unavailable is not an acceptable solution.

Sorry to dig this up again, but wont __STRICT_ANSI__ assume that the program will not use u64 functions (as the program/compiler is supposed to adhere to ansi standards)?

Quoted 8 lines · On Thu, 06 Nov 2003 19:36:39 +0200 Martin Schlemmer <[email protected]> wrote:

Quoted 6 lines · David S. Miller

Quoted 1 line · Thomas Horsten

The following patch fixes the problem:

Making the u64 swabbing functions unavailable is not an acceptable solution.

Quoted 3 lines

Sorry to dig this up again, but wont __STRICT_ANSI__ assume that the program will not use u64 functions (as the program/compiler is supposed to adhere to ansi standards)?

It may make indirect use of inline functions in the kernel headers in question, which themselves need to use the u64 type.

Quoted 11 lines · David S. Miller

Quoted 8 lines · On Thu, 06 Nov 2003 19:36:39 +0200 Martin Schlemmer <[email protected]> wrote:

Quoted 6 lines · David S. Miller

Quoted 1 line · Thomas Horsten

The following patch fixes the problem:

Making the u64 swabbing functions unavailable is not an acceptable solution.

Quoted 6 lines

Quoted 3 lines

Sorry to dig this up again, but wont __STRICT_ANSI__ assume that the program will not use u64 functions (as the program/compiler is supposed to adhere to ansi standards)?

It may make indirect use of inline functions in the kernel headers in question, which themselves need to use the u64 type.

Right, thanks.

Ok, so maybe above is not a case to work on, but if I write an app that use only 32bit data types, and it links to a library that also handles 64bit, it does not matter, as I do not call the functions that handle 64bit data types, no ?

Quoted 4 lines · On Thu, 06 Nov 2003 20:42:59 +0200 Martin Schlemmer <[email protected]> wrote:

Ok, so maybe above is not a case to work on, but if I write an app that use only 32bit data types, and it links to a library that also handles 64bit, it does not matter, as I do not call the functions that handle 64bit data types, no ?

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.

Quoted 4 lines · David S. Miller

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 ... ?

Quoted 8 lines · On Thu, 06 Nov 2003 22:09:29 +0200 Martin Schlemmer <[email protected]> wrote:

Quoted 4 lines · David S. Miller

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.

#else
<code without __u64>
..
#endif

Quoted 2 lines · On Thu, 06 Nov 2003 22:29:12 +0200 Martin Schlemmer <[email protected]> wrote:

If you look at asm/types.h, u64 is kernel only namespace, so in theory that code will not be in userspace.

Replace u64 with __u64 in my examples, the point still stances.

Quoted 4 lines

#else
<code without __u64>
..
#endif

This may not be possible. You cannot account for every internal thing that kernel header routines might need to do or work with. Many structures, which the userspace can't control the layout of etc., makes use of the __u64 type, and we can't just turn off all those things just because -ansi was specified.

We're talking about things like structures that define the userspace ABI into the kernel, they use things like __u64. So what effectively this means is that when you compile with -ansi you are effectively turning off access to several userspace ABIs into the kernel.

And this isn't going to be only some obscrure feature like some CDROM ioctl or whatever, things like "struct stat" use the 64-bit types either directly or indirectly.

Ok - say for instance then you were to write the abi headers - how would you handle a case like this that -ansi forbid type long long, but it have to be in the struct userspace uses to pass data to the kernel/device ?

Quoted 4 lines · On Thu, 06 Nov 2003 23:18:55 +0200 Martin Schlemmer <[email protected]> wrote:

Ok - say for instance then you were to write the abi headers - how would you handle a case like this that -ansi forbid type long long, but it have to be in the struct userspace uses to pass data to the kernel/device ?

I can tell you what cannot happen. You absolutely can't consider ideas like using '__u32 val[2];' and accessor macros, long long or whatever type the platform uses for __u64 has different alignment constraints than the '__u32 val[2]' array thing would.

I believe there is a way to work around this by using the __extension__ keyword when defining the __u64 typedefs. Someone should try playing with that. But this is only going to work when the compiler is GCC.

Quoted 25 lines · David S. Miller

Quoted 2 lines · On Thu, 06 Nov 2003 22:29:12 +0200 Martin Schlemmer <[email protected]> wrote:

If you look at asm/types.h, u64 is kernel only namespace, so in theory that code will not be in userspace.

Replace u64 with __u64 in my examples, the point still stances.

Quoted 4 lines

#else
<code without __u64>
..
#endif

This may not be possible. You cannot account for every internal thing that kernel header routines might need to do or work with. Many structures, which the userspace can't control the layout of etc., makes use of the __u64 type, and we can't just turn off all those things just because -ansi was specified.

We're talking about things like structures that define the userspace ABI into the kernel, they use things like __u64. So what effectively this means is that when you compile with -ansi you are effectively turning off access to several userspace ABIs into the kernel.

Quoted 3 lines

And this isn't going to be only some obscrure feature like some CDROM ioctl or whatever, things like "struct stat" use the 64-bit types either directly or indirectly.

Ok - say for instance then you were to write the abi headers - how would you handle a case like this that -ansi forbid type long long, but it have to be in the struct userspace uses to pass data to the kernel/device ?

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.

Note that "long long" (the underlying type) is valid standards-compliant C99. gcc can handle it when in C89 mode if defined as __extension__ long long IIRC.

On 6 Nov 2003 12:40:55 -0800
"H. Peter Anvin" <[email protected]> wrote:

Quoted 3 lines

Note that "long long" (the underlying type) is valid standards-compliant C99. gcc can handle it when in C89 mode if defined as __extension__ long long IIRC.

That's correct and I've suggested this.

But keep in mind that people with non-GCC compilers will then start complaining.

Quoted 8 lines · On Thu, 06 Nov 2003 22:09:29 +0200 Martin Schlemmer <[email protected]> wrote:

Quoted 4 lines · David S. Miller

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.