Re: alx-0008 - Standardize strtoi(3) and strtou(3) from NetBSD

[Bruno Haible <bruno%clisp.org@localhost>]

Alejandro Colomar wrote:
> > It would be useful to show how a success test looks like, after
> >     strtoi (s, &end, base, min, max, &status)
> > for each of the four frequent use-cases:
> >   -a. expect to parse the initial portion of the string, no coercion,
> >   -b. expect to parse the initial portion of the string, silent coercion,
> >   -c. expect to parse the entire string, no coercion,
> >   -d. expect to parse the entire string, silent coercion.
> > 
> > AFAICS, the success tests are:
> >   -a. status == 0 || status == ENOTSUP
> 
> Correct.
> 
> >   -b. status == 0 || status == ENOTSUP || status == ERANGE
> 
> Correct (but most likely a bug).
> 
> >   -c. status == 0
> 
> Correct.
> 
> >   -d. status == 0 || (status == ERANGE && end > s && *end == '\0')
> 
> You don't need end>s, because that would preclude ERANGE.
> 
> 	status == 0 || (status == ERANGE && end == '\0')
> 
> Aaand, most likely a bug.

Cases b. and d. are not bugs. Often, the programmer knows that treating
a value > ULONG_MAX is equivalent to treating the value ULONG_MAX. These
are *normal* uses of strto[u]l[l]. Often it is the programmer's intent
that the values "4294967297" and "4294967295" produce the same behaviour
(the same error message, for example).

It is for these cases that your specification contains the clamping /
coercion behaviour.

Now, when you look at the table of success tests:

   -a. status == 0 || status == ENOTSUP
   -b. status == 0 || status == ENOTSUP || status == ERANGE
   -c. status == 0
   -d. status == 0 || (status == ERANGE && *end == '\0')

it is immediately clear that the status return convention is ill-designed,
because the returned 'status' is not the only thing a programmer has to test
after calling the function.

> Cases b and d are not real, IMO.  I have never seen code where that is
> wanted, AFAIR, and I analyzed the entire Debian and NetBSD code bases
> looking precisely for that usage.

I disagree. Any use of strtoul that does not test errno wants overflow
to be mapped to ULONG_MAX, that is, is in case b. or d.
Just looking in gnulib and gettext, I find already 6 occurrences:
  gnulib/lib/getaddrinfo.c:299
  gnulib/lib/nproc.c:402
  gnulib/lib/omp-init.c:48
  gettext/gettext-tools/src/msgfmt.c:287
  gettext/gettext-tools/src/msgl-check.c:379
  gettext/gettext-tools/src/read-stringtable.c:561

> > I would therefore propose to change the status value to a bit mask, so that
> > the error conditions "The converted value was out of range and has been
> > coerced" and "The given string contains characters that did not get converted"
> > can be both returned together, without conflicting.
> 
> Because it is theoretical conditions that a real program never wants,
> let's not do that.

If you don't want to do that, I can only repeat what I said in the previous
mail: The proposal *does not achieve the goal* of avoiding the most common
programmer mistakes. For a robust API, the success test should *only* involve
testing the returned 'status', nothing else.

Bruno