On Tue, Sep 20, 2016 at 12:22:41AM -0600, Kevin Locke wrote:
> On 09/19/2016 11:00 PM, David Gibson wrote:
> > On Sun, Sep 18, 2016 at 06:51:59PM -0600, Kevin Locke wrote:
> >> Rather than using fork+pipe+system+waitpid, most of which are only
> >> available on POSIX-like systems, use popen which is also available on
> >> Windows (under the name _popen).
> >
> > Concept looks good, one little wart.
> >
> >> [...]
> >>
> >> -static char *grab_fd(int fd)
> >> +static char *grab_stream(FILE *file)
> >>  {
> >> -  int ret;
> >> -  size_t max, size = 0;
> >> +  size_t max, ret, size = 0;
> >>    char *buffer;
> >>
> >> -  max = 16384;
> >> -  buffer = malloc(max+1);
> >> -  while ((ret = read(fd, buffer + size, max - size)) > 0) {
> >> +  max = BUFSIZ;
> >> +  buffer = malloc(max);
> >> +  while ((ret = fread(buffer+size, 1, max - size, file)) == max - size) {
> >
> > This assumes that fread() will never return a short read except on EOF
> > or error.  I expect that will be true in practice for regular files,
> > but I'm not sure if it's a good idea to rely on it.
> 
> Interesting.  I was under the impression that the fread couldn't short read.
> POSIX describes the return value as "the number of elements successfully
> read which is less than nitems only if a read error or end-of-file is
> encountered."[1]  Now that I think about it, I suppose EINTR could be an
> issue for non-glibc systems.  Is that what you had in mind, or are there
> other issues I'm overlooking?  (Also for fwrite in 6/9?)

Ah..so it does.  I'm afraid I just looked at the Linux man page, not
the POSIX requirements, and it didn't mention this constraint.

I guess it's ok then.  Although.. I do wonder a bit whether we can
trust all implementations to actually comply with this requirement.

> 
> Kevin
> 
> 1.  http://pubs.opengroup.org/onlinepubs/9699919799/functions/fread.html
> 

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature

_______________________________________________
ccan mailing list
ccan@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/ccan

Reply via email to