Re: __STRICT_ANSI__ checks in headers

[Kyle Moffett]

On Oct 01, 2006, at 00:53:43, Andrew Morton wrote:
> On Thu, 28 Sep 2006 10:30:25 +0300
> Ismail Donmez <ismail@xxxxxxxxxxxxx> wrote:
>
> > 28 Eyl 2006 Per 10:06 tarihinde, David Woodhouse ÅunlarÄ  
> > yazmÄÅtÄ:
> > > On Thu, 2006-09-28 at 10:03 +0300, Ismail Donmez wrote:
> > > David, is this ok? It would be good to apply this for 2.6.19 so  
> > > all of KDE would compile ( all of the parts I tested ) with  
> > > kernel-headers.
> > >
> > > Looks good to me.
> >
> > Andrew, now that David gave his blessing , can you push this for  
> > 2.6.19?
>
> Bisection shows that this patch causes these depmod warnings:
>
> WARNING: "snd_card_disconnect" [sound/usb/usx2y/snd-usb-usx2y.ko]  
> has no CRC!
> [etc]
>
> I don't know why that would happen.
>
> From: Ismail Donmez <ismail@xxxxxxxxxxxxx>
>
> __STRICT_ANSI__ usage in types.h header results in compile errors  
> for some userspace packages[1] when used with gcc -ansi flag.  With  
> the suggestion of Kyle Moffett I replace strict ansi checks with  
> __extension__ to tell gcc not to error or warn on gcc extensions.   
> Compile tested on x86 with 2.6.18.

Best guess:  Depmod does some kind of funny type-based expansion and  
hashing of the symbols which doesn't understand the "__extension__"  
keyword.  Probably the simplest thing to do is to add "- 
D__extension__=" to the depmod preprocessing flags.  Alternatively  
you could teach depmod to completely ignore the __extension__ keyword  
when it shows up in the sources, but the former seems like it would  
be much simpler.

Just thinking about it we probably also need to educate sparse about  
__extension__ too.  Perhaps somebody could also add an sparse flag to  
make it warn about nonportable constructs in exported header files.

I'd submit a patch but my knowledge of kernel makefiles and depmod is  
somewhere between zero and none, exclusive.

Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/