Hi Waldemar and Bernhard. First of all sorry for the absent of the detailed explanation of my fixes. I'm going to send a second version of patches after our discussion.
The problem is that fallocate does not pass LTP (Linux Test Project) which checks return code and errno after fallocate execution. Then I've found that fallocate in uClibc does not set errno thus I've decided to fix it according to Linux manpage. But thanks to Bernhard I've also found that posix_fallocate has another behavior: "posix_fallocate() returns zero on success, or an error number on failure. Note that errno is not set." And posix_fallocate in uClibc refers to fallocate (oops). So my first patch is invalid in this place: it's also necessary to change posix_fallocate and posix_fallocate64 to meet requirements of POSIX (make it don't touch errno and just return error code). As for the second patch - fallocate does sign extension incorrectly when 32 bit values are passed (offset and length). It just fills the second word by zeros. E.g. fallocate works incorrectly when offset or length is negative value - in this case kernel thinks that positive values are passed. So I'm going to prepare a second version of patches with better explanation and posix_fallocate fix. Regards, Yuriy Kolerov -----Original Message----- From: Bernhard Reutner-Fischer [mailto:[email protected]] Sent: Thursday, September 17, 2015 12:52 AM To: Waldemar Brodkorb; Yuriy Kolerov Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [PATCH 1/2] libc: fix setting return value and errno in fallocate() On September 16, 2015 9:20:31 PM GMT+02:00, Waldemar Brodkorb <[email protected]> wrote: >Hi Yuriy, > >can you explain why these patches are useful? posix_fallocate does not set errno, the non-standard, Linux fallocate does, according to its manpage (and returns -1 upon error). >Better standard conformance? Testsuite or runtime fixes? So at least the former. Should double check not to regress the posix variant.. ( or maybe that's a bug in the standard, didn't look yet). HTH, > >Thanks > Waldemar _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
