lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 31 Mar 2008 15:07:58 -0700 From: Harvey Harrison <harvey.harrison@...il.com> To: Al Viro <viro@...IV.linux.org.uk> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, linux-kernel@...r.kernel.org Subject: Re: Sparse Question On Mon, 2008-03-31 at 22:58 +0100, Al Viro wrote: > On Mon, Mar 31, 2008 at 02:39:58PM -0700, Harvey Harrison wrote: > > On Mon, 2008-03-31 at 14:15 -0700, Harvey Harrison wrote: > > > Hi Al, > > > > > > Further to eliminating some of the trivial sparse noise in a kernel > > > build, I just can't seem to understand what sparse is warning about: > > > > > > > I should have mentioned, the other block of warnings comes from > > drivers/media/video/videodev.c....again initializing arrays of IOCTLs > > 1 ? 0 : x > > is not valid in contexts where C requires integer constant expressions. > Index in static array initializer is one of those. > > gcc allows it, but its extensions in that area are inconsistent, to say > the least - basically, it goes with "if optimizer can fold that into > constant with this set of options, it will be accepted". With very weird > boundary between accepted and not accepted (as in "reorder arguments of +, > and what had been recognized as constant is not recognized anymore"). > > sparse doesn't even try to duplicate that set of bugs. We _could_ try > to go for a more or less reasonable subset (e.g. ?: with integer constant > expression as the first argument and integer constant expression as > the second or the third resp., depending on the value of the first one, > similar for && and ||), but I'm not all that sure that it's worth doing. > > The fact is, use of what we have for _IOC in such contexts is not just > a gccism, it's ill-defined one. I suspect that the right solution is > to sanitize _that_... > > FWIW, why not simply put division by 0 into the branch that shouldn't > be reached instead of using a variable that doesn't exist and would > blow at ld(1) time? I.e. go with > #define _IOC_TYPECHECK(t) \ > ((sizeof(t) == sizeof(t[1]) && \ > sizeof(t) < (1 << _IOC_SIZEBITS)) ? \ > sizeof(t) : 1/0) > instead. I'd say that trading a pretty name in linker stderr for > compiler error that shows exact location in the source would be > a good bargain... > > Linus, would you object against that in post-2.6.25? Sorry, maybe I'm thick, but how does _IOC_TYPECHECK get pulled into the _IOC_NR use? Harvey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists