On Thu, 15 Dec 2005, Coywolf Qi Hunt wrote:
>
> Two years ago, "[PATCH] use size_t for the broken ioctl numbers" brought in
> the problem.
> <http://lkml.org/lkml/2003/9/7/14> (also FYI:
> <https://lwn.net/Articles/48360/>)
>
> The patch below fixes the bug on BLKGETSIZE64. typeof(size_t) == 32, but we
> expect 64.
> The choice of `size_t' is also a mistake. We should have taken `int'. This
> also affects
> userland linux-kernel-headers.
>
> Or am I missing something? Thanks.
You're missing the fact that we can't just change existing numbers. It
just makes the ioctl not work.
A lot of the "size_t"'s got added because people had mis-understood the
_IOR/W macros, and had done a "sizeof()" by hand, when the macro itself
did the sizeof. Which caused the macro to make the ioctl number be based
on "sizeof(sizeof(realsize))", which is the same as "sizeof(size_t)".
And because we MUST NOT change the ioctl number (regardless of whether the
number shows the correct size or not), those got changed to use "size_t"
to match historical - if incorrect - numbering.
The _IOR/W macros got fixed so that you now _cannot_ use anything but a
real type, so the bug shouldn't happen again, but we're stuck with the old
broken numbers.
The number is just a number, after all. We shouldn't be using the size
encoding in the ioctl number, afaik (since for a _lot_ of them we can't
depend on it anyway).
Linus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
