Date: Wed, 1 Oct 2003 00:27:49 +0200 (CEST)
From: Maciej Zenczykowski <maze@cela.pl>
To: Russell King <rmk@arm.linux.org.uk>
cc: Andrew Morton <akpm@osdl.org>, Arun Sharma <arun.sharma@intel.com>,
       <linux-kernel@vger.kernel.org>, <kevin.tian@intel.com>,
       Matthew Wilcox <willy@debian.org>
Subject: Re: [PATCH] incorrect use of sizeof() in ioctl definitions
In-Reply-To: <20030930223531.B10154@flint.arm.linux.org.uk>
Message-ID: <Pine.LNX.4.44.0310010022320.20935-100000@gaia.cela.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org

> > Matthew's conversion mainly converted things to size_t, but from the looks
> > of it, __u32* is the right thing to use in this case, I think?
> 
> sizeof(__u32*) may not be sizeof(sizeof(__u32*)), so this would be an API
> change...  Therefore, all these wrong entries need to change to size_t
> (preferably with the real type following inside a comment so we don't
> loose useful information.)

I hit this bug a while back - most often it's for 4byte sized objects 
(ints or pointers) on x86 arch (don't know about others).  Unfortunately 
there was a case where it was for an 8 and was wrongly declared via sizeof 
and thus 4.  I'd suggest moving all to single sizeof's and where this 
causes API changes to implement bogus/extra declarations which could then 
possibly be faded out with time.  However currently the glibc kernel 
headers are also similarly screwed.  Obviously this would bloat the kernel 
a little, OTOH for x86 arch I only noticed one case where it didn't end up 
the same whether thru double or single sizeof.  Perhaps we could be lucky 
and have almost as much luck on other archs?

MaZe.

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