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

[Paul Eggert]

On 2025-03-19 13:05, Alejandro Colomar wrote:
> Please comment on the subthread where Bruno mentioned a number of places
> in gnulib and gettext where you use strtoul(3).  I found there a few
> bugs, plus some ways to just simplify with strtou(3).

I looked at the Gnulib commentary in 
<https://lore.kernel.org/liba2i/jx4664ishtl34eg2npdrv5fkfdiczqnlq3vjuacjrupjvh377x@gddcftzgwmfq/>, 
as I assume that's what you're talking about. (I don't hack on gettext 
and will leave Bruno to comment on that.)

For Gnulib, I didn't see any bugs in the three areas mentioned.

The patch suggested to lib/getaddrinfo.c doesn't fix any bugs that I can 
see, and needs an additional wrapper to work anyway, which is 
introducing complexity.

The patch suggested to lib/nproc.c is merely a minor clarity / 
performance improvement (it removes three instructions), and does not 
fix any bugs. Likewise for the patch to lib/omp-init.c. And these 
improvements (where the code mistakenly worried about endptr == NULL) 
fix a mistake that one could make with the proposed strtoi API, so I 
don't see strtoi helping there.

But thanks for the clarity / speedup idea; I installed a patch into 
Gnulib here:

https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=2835ca01722fcd41761383ef289d19797b13b2e8




>> > In particular, use a functional style, with
>> > no side effects (no pointers-to-results). Just return the result you want,
>> > as a struct, and keep the struct simple. Two struct components should
>> > suffice: the scanned numeric value and a success/error indicator.
> 
> That's going to complicate usage significantly.

Please try it and see. You might be surprised at how clean and efficient 
functional programming can be, if done right. Admittedly C doesn't 
always make it easy.