Created attachment 9915 [details]
Allow __USE_ISOC99 to use __u64 too.

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 ~ $

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
> 

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.

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

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

What is the status on this bug? Is the problem still there in recent kernels?
Thanks.

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

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.

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

this has been fixed a different way in current git

Thanks for the update. Closing the bug.