* fread, fwrite with size 0 @ 2016-02-03 8:53 hombre 2016-02-04 4:39 ` Rich Felker 0 siblings, 1 reply; 4+ messages in thread From: hombre @ 2016-02-03 8:53 UTC (permalink / raw) To: musl Hello, I think that fread and fwrite does not return 0 when parameter size is 0 (when nmemb is 0, it does). Clib spec says: If size or nmemb is zero, fread/fwrite returns zero I did the following changes to make it work: fread: from return nmemb; to return len == 0 ? 0 : nmemb; fwrite: from return k == l ? nmemb : k / size; to if (l == 0) return 0; else return k == l ? nmemb : k / size; Regards, Erwin ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: fread, fwrite with size 0 2016-02-03 8:53 fread, fwrite with size 0 hombre @ 2016-02-04 4:39 ` Rich Felker 2016-02-11 0:42 ` Rich Felker 0 siblings, 1 reply; 4+ messages in thread From: Rich Felker @ 2016-02-04 4:39 UTC (permalink / raw) To: musl On Wed, Feb 03, 2016 at 09:53:21AM +0100, hombre wrote: > Hello, > > I think that fread and fwrite does not return 0 when parameter size > is 0 (when nmemb is 0, it does). > Clib spec says: If size or nmemb is zero, fread/fwrite returns zero > > I did the following changes to make it work: > > fread: > from > return nmemb; > to > return len == 0 ? 0 : nmemb; > > fwrite: > from > return k == l ? nmemb : k / size; > to > if (l == 0) > return 0; > else > return k == l ? nmemb : k / size; > > Regards, > Erwin Thanks. Sadly the POSIX version of the text is contradictory on this: "Upon successful completion, fread() shall return the number of elements successfully read which is less than nitems only if a read error or end-of-file is encountered. If size or nitems is 0, fread() shall return 0 and the contents of the array and the state of the stream remain unchanged." First it says that the return value can be less than nitems only if an error of EOF happens, but then it gives another way the return value can be less than nitems (if size is 0). Fortunately the ISO C text is not so broken and agrees with you: "The fread function returns the number of elements successfully read, which may be less than nmemb if a read error or end-of-file is encountered. If size or nmemb is zero, fread returns zero and the contents of the array and the state of the stream remain unchanged." There's another issue I want to fix here too, but I might do it in two commits. Thanks for the report. Rich ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: fread, fwrite with size 0 2016-02-04 4:39 ` Rich Felker @ 2016-02-11 0:42 ` Rich Felker 2016-02-12 15:06 ` Rich Felker 0 siblings, 1 reply; 4+ messages in thread From: Rich Felker @ 2016-02-11 0:42 UTC (permalink / raw) To: musl On Wed, Feb 03, 2016 at 11:39:48PM -0500, Rich Felker wrote: > On Wed, Feb 03, 2016 at 09:53:21AM +0100, hombre wrote: > > Hello, > > > > I think that fread and fwrite does not return 0 when parameter size > > is 0 (when nmemb is 0, it does). > > Clib spec says: If size or nmemb is zero, fread/fwrite returns zero > > > > I did the following changes to make it work: > > > > fread: > > from > > return nmemb; > > to > > return len == 0 ? 0 : nmemb; > > > > fwrite: > > from > > return k == l ? nmemb : k / size; > > to > > if (l == 0) > > return 0; > > else > > return k == l ? nmemb : k / size; > > > > Regards, > > Erwin > > Thanks. Sadly the POSIX version of the text is contradictory on this: > > "Upon successful completion, fread() shall return the number of > elements successfully read which is less than nitems only if a read > error or end-of-file is encountered. If size or nitems is 0, fread() > shall return 0 and the contents of the array and the state of the > stream remain unchanged." > > First it says that the return value can be less than nitems only if an > error of EOF happens, but then it gives another way the return value > can be less than nitems (if size is 0). > > Fortunately the ISO C text is not so broken and agrees with you: > > "The fread function returns the number of elements successfully read, > which may be less than nmemb if a read error or end-of-file is > encountered. If size or nmemb is zero, fread returns zero and the > contents of the array and the state of the stream remain unchanged." > > There's another issue I want to fix here too, but I might do it in two > commits. Thanks for the report. I'm fixing this by adding: if (!size) nmemb = 0; to the top of both functions. This is preferable because, at least for fread, I'm also going to have to check for nmemb>=SIZE_MAX/size in order to properly handle this case (see glibc bug 19165), and having already ruled out size==0 (i.e. only doing the overflow check in the 'else' path for the above 'if') makes that division safe. Rich ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: fread, fwrite with size 0 2016-02-11 0:42 ` Rich Felker @ 2016-02-12 15:06 ` Rich Felker 0 siblings, 0 replies; 4+ messages in thread From: Rich Felker @ 2016-02-12 15:06 UTC (permalink / raw) To: musl On Wed, Feb 10, 2016 at 07:42:34PM -0500, Rich Felker wrote: > On Wed, Feb 03, 2016 at 11:39:48PM -0500, Rich Felker wrote: > > On Wed, Feb 03, 2016 at 09:53:21AM +0100, hombre wrote: > > > Hello, > > > > > > I think that fread and fwrite does not return 0 when parameter size > > > is 0 (when nmemb is 0, it does). > > > Clib spec says: If size or nmemb is zero, fread/fwrite returns zero > > > > > > I did the following changes to make it work: > > > > > > fread: > > > from > > > return nmemb; > > > to > > > return len == 0 ? 0 : nmemb; > > > > > > fwrite: > > > from > > > return k == l ? nmemb : k / size; > > > to > > > if (l == 0) > > > return 0; > > > else > > > return k == l ? nmemb : k / size; > > > > > > Regards, > > > Erwin > > > > Thanks. Sadly the POSIX version of the text is contradictory on this: > > > > "Upon successful completion, fread() shall return the number of > > elements successfully read which is less than nitems only if a read > > error or end-of-file is encountered. If size or nitems is 0, fread() > > shall return 0 and the contents of the array and the state of the > > stream remain unchanged." > > > > First it says that the return value can be less than nitems only if an > > error of EOF happens, but then it gives another way the return value > > can be less than nitems (if size is 0). > > > > Fortunately the ISO C text is not so broken and agrees with you: > > > > "The fread function returns the number of elements successfully read, > > which may be less than nmemb if a read error or end-of-file is > > encountered. If size or nmemb is zero, fread returns zero and the > > contents of the array and the state of the stream remain unchanged." > > > > There's another issue I want to fix here too, but I might do it in two > > commits. Thanks for the report. > > I'm fixing this by adding: > > if (!size) nmemb = 0; > > to the top of both functions. This is preferable because, at least for > fread, I'm also going to have to check for nmemb>=SIZE_MAX/size in > order to properly handle this case (see glibc bug 19165), and having > already ruled out size==0 (i.e. only doing the overflow check in the > 'else' path for the above 'if') makes that division safe. I'm going to hold off on doing anything about the latter issue (overflow/saturating mul) because the kernel is not even able to handle these read requests correctly, so we would not get any immediate correctness 'benefit' anyway without lots of hacks to work around the kernel's [mis?]behavior. But the size==0 case should be working correctly now. Rich ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-02-12 15:06 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-02-03 8:53 fread, fwrite with size 0 hombre 2016-02-04 4:39 ` Rich Felker 2016-02-11 0:42 ` Rich Felker 2016-02-12 15:06 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).