On Wed, Nov 27, 2013 at 11:03:47AM +0100, Aurelien Jarno wrote: > In my case, I am *not* talking about FUSE code, but programs using this > ioctl from userland. Changing the kernel FUSE code won't fix the problem > I reported. I wasn't aware of the fact that there were broken userspace programs up until now --- and things have like this for well over a decade, with no one complaining until now, which gives you a hint about how prevelant this problem actually is. > People who do the things correctly lookup the argument type in > <linux/fs.h>, they see it's a long and then use a long in their code. And > they are right. The bare minimum would be to add a comment close to the > definition to explain to use an int and not a long. The documentation is specifies the FS_IOC_GETFLAGS and FS_IOC_SETFLAGS takes an int * and int, respectively, in the ioctl_list man page. As far as the "self documenting" ioctl numbering is concerned, I've always considered it "mostly harmless", but never as authoratative documentation. Hence, trying to use words such as "right" or "wrong" is not particularly interested as far as I'm concerned. (I'm reminded of the story of the time when Richard Stallman blindly steped into the crosswalk, and was almost killed by a car running the red light. Someone held him back and said, "didn't you see that car? He would have almost killed you!". To which Richard said, "but he would have been in the wrong.") In any case, sure, we can add a documentation to the header file in the kernel sources, and the glibc folks will need to be asked to fix up /usr/include/linux/fs.h (which is not the same as the include/linux/fs.h in the kernel). But it doesn't change the fact that it is bup and libexplain that will need to be changed, regardless of whether they were in the "right" or in the "wrong". If the sense of moral superiority makes them more willing to fix their code, fine. Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
