hello. I'm pretty sure fpritf can return an error that means there
was an i/o error or that something about the underlying file descriptor
needs investigating.
-Brian
On Aug 29, 8:25am, Rob Newberry wrote:
} Subject: Re: NetBSD bug/misbehavior in vdprintf
} >>> NetBSD's imple
Date:Sat, 29 Aug 2020 20:09:34 - (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID:
| implies that stdio should work with non-blocking file descriptors.
Depending upon your definition of "work" that might be stretching what it
says a little. At the
In article <20200829174525.ga25...@bec.de>,
Joerg Sonnenberger wrote:
>
>It is, there is always some internal buffering for fprintf, so in
>principle you can flush, ack the error, flush again etc.
Indeed,
https://pubs.opengroup.org/onlinepubs/9699919799/functions/fputc.html
lists all the
On Sat, Aug 29, 2020 at 08:25:42AM -0700, Rob Newberry wrote:
> >>> NetBSD's implementation of vdprintf makes a special check -- if the
> >>> descriptor is in non-blocking mode, it needs to be a regular file (I
> >>> think I read that code correctly). But it apparently doesn't have this
> >>>
Date:Sat, 29 Aug 2020 08:25:42 -0700
From:Rob Newberry
Message-ID: <470850f0-0d61-4b5d-b3d7-f24c46fd4...@mac.com>
| Is the interface any different for fprintf than dprintf?
fprintf (via the FILE) has a buffer - fprintf copies the (formatted)
data to the buffer,
>>> NetBSD's implementation of vdprintf makes a special check -- if the
>>> descriptor is in non-blocking mode, it needs to be a regular file (I
>>> think I read that code correctly). But it apparently doesn't have this
>>> check problem for vfprintf. I think it's been there a long time (since
On Fri, Aug 28, 2020 at 10:02:51PM -, Christos Zoulas wrote:
> In article ,
> Rob Newberry wrote:
> >(Also posting to tech-userlevel...)
> >
> >
> >NetBSD's implementation of vdprintf makes a special check -- if the
> >descriptor is in non-blocking mode, it needs to be a regular file (I
>
In article ,
Rob Newberry wrote:
>(Also posting to tech-userlevel...)
>
>
>NetBSD's implementation of vdprintf makes a special check -- if the
>descriptor is in non-blocking mode, it needs to be a regular file (I
>think I read that code correctly). But it apparently doesn't have this
>check
(Also posting to tech-userlevel...)
NetBSD's implementation of vdprintf makes a special check -- if the descriptor
is in non-blocking mode, it needs to be a regular file (I think I read that
code correctly). But it apparently doesn't have this check problem for
vfprintf. I think it's been
