Hi Paul,
On Wed, Mar 19, 2025 at 01:39:00PM -0700, Paul Eggert wrote:
> 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.)
Yes, I was referring to those.
> 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.
Agree. gnulib had dead code and not-very-readable code, but no
misbehavior.
Although, I think not reporting errors or warnings on saturation needs
justification.
> 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.
The test ==NULL would never make sense in strtoi(3) because it
guarantees setting *endp even on EINVAL. Some programmers are paranoid
with strtol(3) and check for NULL, because in some systems it may keep
it uninitialized on EINVAL, but that's not portable at all. So yes,
strtoi(3) should remove that issue.
>
> 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
Thanks, those changes look good. BTW, what do you think of using
strspn(3) to simplify the c_isspace loop?
However, would you mind clarifying why you don't diagnose huge values in
the two places that you have updated?
> > > > 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.
Here's an example of parsing a time_t:
time_t t;
if (a2i(time_t, &t, ...) == -1)
err(1, "a2i");
If you need to store it in a struct, you need to know what a time_t is
in the first place:
struct foo {
long val;
int err;
}
struct foo ret;
ret = f(time_t, ...);
if (ret.err != 0)
err(1, "f");
How do I know which variant of struct foo I need?
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature