[PATCH 1/2] libc: fix setting return value and errno in fallocate()

Bernhard Reutner-Fischer rep.dot.nop at gmail.com
Thu Sep 17 19:27:40 UTC 2015


On September 17, 2015 6:16:48 PM GMT+02:00, Yuriy Kolerov <Yuriy.Kolerov at synopsys.com> wrote:
>Hi Rich.
>
>fallocate must return 0 or -1. However posix_fallocate my return an
>error code. So I think it would be better to allow posix_fallocate
>change errno as fallocate does it and fix posix_fallocate return value
>according to POSIX.

fallocate () should be implemented on top of posix_fallocate, yes.

TIA,
>
>Regards,
>Yuriy Kolerov
>
>
>-----Original Message-----
>From: Rich Felker [mailto:dalias at aerifal.cx] On Behalf Of Rich Felker
>Sent: Thursday, September 17, 2015 7:08 PM
>To: Yuriy Kolerov
>Cc: Bernhard Reutner-Fischer; Waldemar Brodkorb; uclibc at uclibc.org;
>Vineet.Gupta1 at synopsys.com; Alexey.Brodkin at synopsys.com;
>Francois.Bedard at synopsys.com
>Subject: Re: [PATCH 1/2] libc: fix setting return value and errno in
>fallocate()
>
>On Thu, Sep 17, 2015 at 03:56:55PM +0000, Yuriy Kolerov wrote:
>> 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).
>
>Not-touching-errno is not a POSIX requirement. This is just a case of
>an over-aggressive man page documenting glibc-specific behavior that is
>not standard and should not be relied upon by applications. You can see
>here that there is no such requirement (by default any function in the
>standard is allowed to modify errno unless it's specified not to):
>
>http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_fallocate.html
>
>Rich




More information about the uClibc mailing list