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. Cheers, Andreas -- 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
