Hello Andreas, On Wed, Sep 21, 2011 at 7:25 AM, Andreas Dilger <adilger@xxxxxxxxx> wrote: > On 2011-09-20, at 10:11 PM, Michael Kerrisk wrote: >> Thanks for this patch. As noted in another mail, Lucian also sent a >> patch for FALLOC_FL_PUNCH_HOLE, and I applied his patch first, and >> then added some pieces from yours, as well as some of my own edits. >> >> However, the addition of a second class of operation to the man page >> made it clear that some significant restructuring of the page is >> required. So I substantially reworked the page, including the >> preexisting material on the default "file allocation" operation (Dave >> C please note). >> >> .TP >> .B EINVAL >> .I offset >> was less than 0, or >> .I len >> was less than or equal to 0. > > I wasn't sure if this is a bug in the manpage or actually how it is done > in the kernel, but it seems this is a kernel implementation issue... > > Does it make sense to return an error if len == 0? That just adds extra > complexity on the part of the application, and doesn't reduce complexity > in the kernel (whether the kernel checks for len == 0 and returns 0 or > -EINVAL is not any different). read() and write() and malloc() all allow > a length of zero to succeed, since applications may compute this length > and sometimes it is zero. Good point. I agree: for comfort of userspace application writers and for consistency with related interfaces, len == 0 shouldn't be an error. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface"; http://man7.org/tlpi/ -- 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
