linux-kernel - Re: Sparse Question

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080331215835.GM9785@ZenIV.linux.org.uk>
Date:	Mon, 31 Mar 2008 22:58:35 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Harvey Harrison <harvey.harrison@...il.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: Sparse Question

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