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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
