login
Login
/
Register
Search
Forums
News
Blogs
Features
Site
Home
»
Mailing list archives
»
linux-kernel
»
2008
»
March
»
31
Re: Sparse Question
view
thread
!MAILaRCHIVE_VOTE_RePLACE
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
[view in full thread]
From:
Harvey Harrison <harvey.harrison@...>
To: Al Viro <viro@...>
Cc: Linus Torvalds <torvalds@...>, <linux-kernel@...>
Subject:
Re: Sparse Question
Date: Monday, March 31, 2008 - 6:07 pm
On Mon, 2008-03-31 at 22:58 +0100, Al Viro wrote:
quoted text
> 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 --
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
Messages in current thread:
Re: Sparse Question
, Al Viro
, (Mon Mar 31, 5:58 pm)
[PATCH] asm-generic: suppress sparse warning in ioctl.h
, Harvey Harrison
, (Mon Mar 31, 6:26 pm)
Re: Sparse Question
, Harvey Harrison
, (Mon Mar 31, 6:07 pm)
Re: Sparse Question
, Harvey Harrison
, (Mon Mar 31, 6:16 pm)
Navigation
Create content
Mailing list archives
Recent posts
Popular discussions
linux-kernel
:
Tarkan Erimer
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Greg Kroah-Hartman
[PATCH 004/196] Chinese: add translation of SubmittingPatches
Bart Van Assche
Integration of SCST in the mainstream Linux kernel
Eric Sandeen
Re: [RFC] Heads up on sys_fallocate()
git
:
linux-netdev
:
Gerrit Renker
[PATCH 15/37] dccp: Set per-connection CCIDs via socket options
Jarek Poplawski
[PATCH] pkt_sched: Destroy gen estimators under rtnl_lock().
David Miller
[GIT]: Networking
Antonio Almeida
HTB accuracy for high speed
openbsd-misc
:
Colocation donated by:
Who's online
There are currently
1 user
and
521 guests
online.
Online users
henrywatson
Syndicate