Bug 7724 - asm/types.h should define __u64 if isoc99
asm/types.h should define __u64 if isoc99
Status: CLOSED PATCH_ALREADY_AVAILABLE
Product: Platform Specific/Hardware
Classification: Unclassified
Component: Other
i386 Linux
: P2 blocking
Assigned To: other_other
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-21 08:12 UTC by Roy Marples
Modified: 2008-04-15 20:31 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.19
Tree: Mainline
Regression: ---


Attachments
Allow __USE_ISOC99 to use __u64 too. (361 bytes, patch)
2006-12-21 08:15 UTC, Roy Marples
Details | Diff
Patch all archs (6.66 KB, patch)
2006-12-21 13:00 UTC, Roy Marples
Details | Diff

Description Roy Marples 2006-12-21 08:12:21 UTC
Most recent kernel where this bug did *NOT* occur:
Distribution: Gentoo
Hardware Environment: n/a
Software Environment: 2.6.18 kernels and lower
Problem Description:

Steps to reproduce:
Download dhcpcd-3.0.7 from http://dhcpcd.berlios.de/
extract it and type 'make'
Watch it fail with this error
cc -D_BSD_SOURCE -O2 -pipe -pedantic -std=c99 -Wall -Wunused -Wimplicit
-Wshadow -Wformat=2 -Wmissing-declarations -Wno-missing-prototypes
-Wwrite-strings -Wbad-function-cast -Wnested-externs -Wcomment -Winline
-Wchar-subscripts -Wcast-align -Wno-format-nonliteral -Wsequence-point -Wextra
-Wdeclaration-after-statement -c interface.c
In file included from /usr/include/linux/rtnetlink.h:5,
                 from interface.c:33:
/usr/include/linux/if_link.h:43: error: expected specifier-qualifier-list
before 
Comment 1 Roy Marples 2006-12-21 08:15:13 UTC
Created attachment 9915 [details]
Allow __USE_ISOC99 to use __u64 too.
Comment 2 Mike Frysinger 2006-12-21 08:49:04 UTC
your change breaks strict ansi ... u64 should not be defined while strict ansi
is in effect

i think your trouble lies with the fact that -std=c99 turns on strict ansi
while -std=gnu99 does not

vapier@G5[ppc] 0 ~ $ echo "" | cpp -dD | grep -i ansi
vapier@G5[ppc] 0 ~ $ echo "" | cpp -dD -std=c99 | grep -i ansi
#define __STRICT_ANSI__ 1
vapier@G5[ppc] 0 ~ $ echo "" | cpp -dD -std=gnu99 | grep -i ansi
vapier@G5[ppc] 0 ~ $
Comment 3 Andrew Morton 2006-12-21 12:45:15 UTC
On Thu, 21 Dec 2006 08:17:10 -0800
bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=7724
> 
>            Summary: asm/types.h should define __u64 if isoc99
>     Kernel Version: 2.6.19
>             Status: NEW
>           Severity: blocking
>              Owner: other_other@kernel-bugs.osdl.org
>          Submitter: uberlord@gentoo.org
> 
> 
> Most recent kernel where this bug did *NOT* occur:
> Distribution: Gentoo
> Hardware Environment: n/a
> Software Environment: 2.6.18 kernels and lower
> Problem Description:
> 
> Steps to reproduce:
> Download dhcpcd-3.0.7 from http://dhcpcd.berlios.de/
> extract it and type 'make'
> Watch it fail with this error
> cc -D_BSD_SOURCE -O2 -pipe -pedantic -std=c99 -Wall -Wunused -Wimplicit
> -Wshadow -Wformat=2 -Wmissing-declarations -Wno-missing-prototypes
> -Wwrite-strings -Wbad-function-cast -Wnested-externs -Wcomment -Winline
> -Wchar-subscripts -Wcast-align -Wno-format-nonliteral -Wsequence-point -Wextra
> -Wdeclaration-after-statement -c interface.c
> In file included from /usr/include/linux/rtnetlink.h:5,
>                  from interface.c:33:
> /usr/include/linux/if_link.h:43: error: expected specifier-qualifier-list
> before ___u64_
> In file included from /usr/include/linux/rtnetlink.h:7,
>                  from interface.c:33:
> /usr/include/linux/neighbour.h:92: error: expected specifier-qualifier-list
> before ___u64_
> make: *** [interface.o] Error 1
> 


Comment 4 Anonymous Emailer 2006-12-21 12:54:14 UTC
Reply-To: davem@davemloft.net

From: Andrew Morton <akpm@osdl.org>
Date: Thu, 21 Dec 2006 12:49:54 -0800

> >            Summary: asm/types.h should define __u64 if isoc99

Platform specific bug, and has nothing to do with networking.

This problem will occur with any user visible interface definition
that uses __u64, and there are several both in and outside the
networking.

x86 and perhaps others protect the __u64 definition with:

	defined(__GNUC__) && !defined(__STRICT_ANSI__)

for whatever reason, probably to avoid "long long" or something like
that.  But even that theory makes no sense.

I do not make this protection on any of the sparc ports, even 32-bit
sparc, for example, so I find it really strange that x86 does this.

Comment 5 Ismail Donmez 2006-12-21 12:58:38 UTC
21 Ara 2006 Per 22:58 tarihinde, David Miller şunları yazmıştı: 
> From: Andrew Morton <akpm@osdl.org>
> Date: Thu, 21 Dec 2006 12:49:54 -0800
>
> > >            Summary: asm/types.h should define __u64 if isoc99
>
> Platform specific bug, and has nothing to do with networking.
>
> This problem will occur with any user visible interface definition
> that uses __u64, and there are several both in and outside the
> networking.

This bug hit KDE modules (kdebase/kdemultimedia/kdetv/...) many times, I 
workarounded with #undef ing __STRICT_ANSI__ before including kernel headers 
which is well ugly but works.

> x86 and perhaps others protect the __u64 definition with:
>
> 	defined(__GNUC__) && !defined(__STRICT_ANSI__)
>
> for whatever reason, probably to avoid "long long" or something like
> that.  But even that theory makes no sense.

Indeed this restriction just breaks userspace apps.

Regards,
ismail

Comment 6 Roy Marples 2006-12-21 13:00:30 UTC
Created attachment 9919 [details]
Patch all archs

Patch all arches to allow __u64 if __USE_ISOC99 if they protect it with
__STRICT_ANSI__

This has already been sent to the LKML
Comment 7 Natalie Protasevich 2007-08-26 12:06:53 UTC
What is the status on this bug? Is the problem still there in recent kernels?
Thanks.
Comment 8 Mike Frysinger 2007-08-26 13:25:36 UTC
presumably the bug wouldnt still be open if it were fixed

multiple threads have happened on lkml on the topic but nothing has been merged
Comment 9 Natalie Protasevich 2007-08-26 13:33:31 UTC
Hah, I wish that was the case. Lots of stale bugs are hanging around, some have been resolved for a while... Can you please give some pointers of such discussions? I am also changing the category to platform related.
Thanks.
Comment 10 Natalie Protasevich 2008-04-15 15:59:54 UTC
I don't see the patch in #6 has been submitted. Roy, can you post it to LKML so it gets reviewed and further discussed (hopefully)?
Comment 11 Mike Frysinger 2008-04-15 20:07:22 UTC
this has been fixed a different way in current git
Comment 12 Natalie Protasevich 2008-04-15 20:31:20 UTC
Thanks for the update. Closing the bug.

Note You need to log in before you can comment on or make changes to this bug.