Hi Bruno, On Thu, Mar 20, 2025 at 12:12:10AM +0100, Alejandro Colomar wrote: > > > > > > -b. status == 0 || status == ENOTSUP || status == ERANGE > > > > > > > > > > Correct (but most likely a bug). > > > > > > Actually, now I remember that status can be NULL, in which case it's not > > > reported. This is a case where you could check for errors with a > > > simpler expression: > > > > > > end != str > > > > > > but (status == 0 || status == ENOTSUP || status == ERANGE) is still a > > > reasnoable one. > > > > Unfortunately, with a comment like this, you make things more complicated, > > not simpler. I was hoping for an API where success can be determined by > > looking at 'status' in all four cases, and the "simple" solution that you > > are recommending now is: > > -a. look at status > > -b. look at end > > -c. look at status > > -d. look at status AND end. > > > > > I need to update the specification to mention that status can be NULL. > > > > Why do so? This adds text to the specification, making the specification > > more complex (=> longer to understand, harder to remember). The ability > > to pass NULL for rstatus is not a useful feature. > > Hmmm, in Debian, there's exactly one place where this happens, and it's > a test case, so I guess it's fine if we break it. > > <https://sources.debian.org/src/mk-configure/0.37.0-2/tests/mkc_features/tool/test_features1.cxx/?hl=118#L118> > > And there are 0 such calls in NetBSD trunk: > > alx@devuan:~/src/bsd/netbsd/trunk$ find -type f \ > | grep '\.[ch]$' \ > | xargs grep -l '\<strto[iu]\>' \ > | xargs pcre2grep -Mn '(?s)\bstrto[iu] *\([^;]*(NULL|0)\)'; > > So we could tighten the specification to require a non-null pointer. > I would be okay with that. I've reported this to NetBSD. Let's see what they think about it. <https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=59199> Have a lovely night! Alex -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature