I just want to point out that we already return -1 for mmap allocation
failures in the positional argument code.
- todd
> But you do find careful checks in unusually well-written software
> (abbreviated):
>
> /usr/src/usr.sbin/ntpd/ntpd.c
> int writefreq(double d) {
> r = fprintf(freqfp, "%.3f\n", d * 1e6); /* scale to ppm */
> if (r < 0 || fflush(freqfp) != 0) {
>
> So, our current libc can trick nt
Hi Theo,
Theo de Raadt wrote on Wed, Jul 26, 2017 at 11:27:03PM -0600:
> Ted Unangst wrote:
>> returning -1 to indicate error, ignoring the possibility of short
>> output, seems like the option that results in less damage. as an
>> application author, it's the only behavior i can reasonably code
Hi Ted,
Ted Unangst wrote on Thu, Jul 27, 2017 at 01:08:24AM -0400:
> Ingo Schwarze wrote:
>> So i say in all cases above, return -1, set ENOMEM, and it doesn't
>> matter much whether anything is printed, except that asprintf(3)
>> must of course free(3) any allocated memory before returning and
Here's my take.
Internally if a intentional errno is produced, the functions should
cease motion and return -1 to indicate error.
However, these functions should probably guard against unintentional
errno changes. Using save_errno method.
I thought snprintf should maybe be a little different.
> yeah. the number of bytes returned seems like a mistake in the api design.
sorry, but that comes off like a clever soundbite. the return value
informs about the expansion size after the format strings processing,
and i am sure someone has used that information in a place where it
was useful. e
Ingo Schwarze wrote:
> So i say in all cases above, return -1, set ENOMEM, and it doesn't
> matter much whether anything is printed, except that asprintf(3)
> must of course free(3) any allocated memory before returning and
> set the pointer to NULL.
yeah. the number of bytes returned seems like a
Hi Theo,
Theo de Raadt wrote on Wed, Jul 26, 2017 at 08:07:53AM -0600:
> Ingo Schwarze wrote:
>> The current behaviour of our implementation is to return the number
>> of characters printed *and* set errno = ENOMEM.
> I expect it should not set errno. As a general rule, errno should
> only be s
Hi,
now we have conflicting and incomplete opinions. What should
"prefix %.500f postfix", 1.0
and
"%s %.500f %s", "prefix", 1.0, "postfix"
do if the %f fails with ENOMEM?
Currently,
1. [f]printf(..., "prefix %.500f postfix", 1.0)
prints nothing, returns 7, sets ENOMEM
On Wed, 26 Jul 2017 12:10:53 +0200, Ingo Schwarze wrote:
> As related data points, for EOVERFLOW, we do always return -1,
> and for EILSEQ, we changed the code some time ago to return -1 -
> even though in both of these cases, it is not completely obvious
> whether those should be considered "outp
> > From: "Theo de Raadt"
> > Date: Wed, 26 Jul 2017 08:07:53 -0600
> >
> > > The current behaviour of our implementation is to return the number
> > > of characters printed *and* set errno = ENOMEM.
> >
> > I expect it should not set errno. As a general rule, errno should
> > only be set if an
> From: "Theo de Raadt"
> Date: Wed, 26 Jul 2017 08:07:53 -0600
>
> > The current behaviour of our implementation is to return the number
> > of characters printed *and* set errno = ENOMEM.
>
> I expect it should not set errno. As a general rule, errno should
> only be set if an error has been
> The current behaviour of our implementation is to return the number
> of characters printed *and* set errno = ENOMEM.
I expect it should not set errno. As a general rule, errno should
only be set if an error has been indicated. Other short operations
don't set errno.
Hi,
what should printf(3) return on %e/%f/%g/%a malloc(3) failure?
Neither POSIX nor our manual page seem fully conclusive.
POSIX says:
The fprintf() and printf() functions may fail if:
[ENOMEM] Insufficient storage space is available.
RETURN VALUE
Upon successful completion, the fprin
14 matches
Mail list logo
