Messages in this thread | | | From | Michael Kerrisk <> | Date | Wed, 21 Sep 2011 07:49:33 +0200 | Subject | Re: [PATCH] fallocate.2: add FALLOC_FL_PUNCH_HOLE flag definition |
| |
Hello Andreas,
On Wed, Sep 21, 2011 at 7:25 AM, Andreas Dilger <adilger@dilger.ca> 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-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/
| |