linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arkadiusz Drabczyk <arkadiusz@drabczyk.org>
To: Walter Harms <wharms@bfs.de>
Cc: "linux-man@vger.kernel.org" <linux-man@vger.kernel.org>
Subject: Re: [PATCH] fread.3: return value
Date: Thu, 18 Jun 2020 21:16:44 +0200	[thread overview]
Message-ID: <20200618191644.v74spg2nquf4qtyv@comp.lan> (raw)
In-Reply-To: <726938c5daec4d5fbe7e85a121eff984@bfs.de>

On Thu, Jun 18, 2020 at 02:32:02PM +0000, Walter Harms wrote:
> >If the requested size is 4 but there are only 3 bytes left then
> >fread() will return 0, no matter what's the value of nmemb because
> >it's not able to read even a single item and feof() will return
> >non-zero. I think that this is explained clearly enough in the
> >manpage.
> 
> IMHO i would be more clear to drop that "short item count". 
> "If an error occurs, or the end of the file is reached, the  return value is zero"

But the thing is that return value does not have to be zero, at least
when the end of the file is reached. Check this:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
  FILE *fp = fopen("/bin/sh", "rb");
  if (!fp) {
    perror("fopen");
    return EXIT_FAILURE;
  }

  fseek(fp, -10, SEEK_END);

  unsigned char buffer[12];

  size_t ret = fread(buffer, 4, 3, fp);
  if (ret != 3) {
    fprintf(stderr, "fread() failed: %zu\n", ret);
    printf("feof: %d\n", feof(fp) ? 1 : 0);
    exit(EXIT_FAILURE);
  }

  fclose(fp);

  exit(EXIT_SUCCESS);
}

Output:

fread() failed: 2
feof: 1

> >That is interesting. POSIX
> >https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/ says
> >that "If a partial element is read, its value is unspecified.". But as
> >fread() returns number of items it has successfully read the returned
> >value should always be checked and it's different than requested nmemb
> >it means an error and I guess there is no way to tell how many bytes
> >have been partially read - for example if size == 4 and nmemb == 1 and
> >returned value is 0 you don't know if fread() read 1, 2 or 3 bytes.
> 
> the GNU version fills the buffer with the remaining bytes

And so does libuClibc-0.9.33.2 and musl 1.1.20-git-79-gd6c855c that I
have at hand. It's probably the easiest implementation of fread(). 

> but returns 0.

That's not always the case as I showed above.

-- 
Arkadiusz Drabczyk <arkadiusz@drabczyk.org>

      reply	other threads:[~2020-06-18 19:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-16 18:26 [PATCH] fread.3: Explain that file position is moved after calling fread()/fwrite() Arkadiusz Drabczyk
2020-06-16 19:00 ` Jakub Wilk
2020-06-16 22:50   ` Arkadiusz Drabczyk
2020-06-17  7:46     ` AW: " Walter Harms
2020-06-17 17:30       ` Arkadiusz Drabczyk
2020-06-18  8:37         ` AW: " Walter Harms
2020-06-18 11:43           ` Arkadiusz Drabczyk
2020-06-18 14:32             ` AW: [PATCH] fread.3: return value Walter Harms
2020-06-18 19:16               ` Arkadiusz Drabczyk [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200618191644.v74spg2nquf4qtyv@comp.lan \
    --to=arkadiusz@drabczyk.org \
    --cc=linux-man@vger.kernel.org \
    --cc=wharms@bfs.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).