Questionable behavior of strtoi(3bsd) / strtou(3bsd)

[Guillem Jover]

Hi!

On Sun, 2024-01-07 at 21:23:51 +0100, Alejandro Colomar wrote:
> Guillem wrote:
> > Because in the same way you can duplicate the endptr check, you could
> > as well do the same for the range checks.
> 
> Nope.  strtoi(3) is discarding that information, which cannot be
> recovered in any way (except parsing again with strtoimax(3)).  ENOTSUP
> comes from strtoimax(3)'s endptr, so one can check `(*end != '\0')` if
> status == ERANGE.  But the only way strtoimax(3) reports ERANGE is
> precisely by setting errno (which strtoi(3bsd) clears, so you can't
> check errno afterwards; that ERANGE is simply lost).

Ah, sorry, you are right, I only scanned the function very briefly, and
didn't spot that the ECANCELED and ENOTSUP cases were not doing early
returns (the function is _always_ clamping the values as documented),
which is what would have allowed to perform the range check from the
caller side. Although at that point perhaps you might as well just
open code the strtoimax() handling logic anyway.

> > I'm also not sure whether
> > changing the semantics now could cause other issues though.
> 
> I'm also concerned about it.  I'll check NetBSD's code in case I find
> something that breaks there.  There's also the possibility that fixing
> this design problem would silently fix some bugs.  I'll check if that's
> the case, which will help get the fix applied.  :)

Ah, thanks for the analysis you did on the other sub-thread, I guess
though there's the potential for third-party projects that are not part
of the NetBSD source tree, to opportunistically use a system strtoi(),
which could also become bogus. A quick scan over the results from a
Debian codesearch revealed some uses that seem to match this API:

  https://codesearch.debian.net/search?q=%5B%5Ea-z_%5Dstrtoi%5B%5B%3Aspace%3A%5D%5D*%5C%28&literal=0&perpkg=1&page=8

But I didn't stop to check whether these would become bogus or not.
Searches through google code search or github might reveal more users,
but that might be tiresome to go through (or you might not feel like
using those services at all :D).

> > If the function changes in NetBSD, I'm happy to import those changes,
> > but I don't think I'd be comfortable doing that unilaterally in libbsd.
> > I'd suggest you file a bug report in the NetBSD bug tracker.
> 
> Sure; will do.  I'll send a few more emails to this thread with the
> results of my search in NetBSD's code, and when I have all the info I
> want, I'll file a bug there.

Thanks for filing the report! You might want to mention explicitly
there the analysis you have done on their source tree, as I'd assume
they could easily skip reading the referenced thread.

> Bon any,

(Igualment! :)

Thanks,
Guillem