Hi Alex, At 2025-09-18T22:50:42+0200, Alejandro Colomar wrote: > On Thu, Sep 18, 2025 at 03:19:52PM -0500, G. Branden Robinson wrote: > > I have to admit I haven't put a priority on this, due to a few > > factors. > > > > 1. No exogenous factor is pressing to bump our gnulib submodule to > > the 2025-07 stable tag. However, that tag _is_ almost three > > months old, and I can't delay forever because gnulib > > releases/tags have a lifespan of only 1 year. > > When 202601 is out, you'll get streq() and memeq(), and I'll send > patches for them. :)
Looking forward to that--those should have been in libc in the 1980s! I
wonder by how many orders of magnitude string (in)equality comparisons
exceed string collation order comparisons.
> > 3. Within the past few months I refactored some of the same code
> > you're touching in this patch to more consistently use our
> > bespoke `array_length()` solution to this problem.[1]
>
> I'd strongly recommend using countof(), which is now standard.
> It has some direct benefits:
>
> - Using a standard name, which avoids contributors having to figure
> out which name you've invented for this operation.
Sure...after an initial period of unfamiliarity because it _is_ a new
thing. :)
I don't disagree with the migration; it just seems like an "eventually"
thing to me.
> - It removes maintenance burden from groff(1), since it's maintained
> by gnulib.
I don't think much maintenance burden remains. But bug #66518 is all
about this sort of housecleaning.
> If you need me to rebase on top of your changes to reduce your work
> applying, I can do that.
That might be necessary given the aforementioned commits.
> > I'm not _opposed_ to migrating to `countof()`; it simply seems to me
> > a relatively cutting-edge modernization that brings little practical
> > benefit.
>
> In the gnulib vesion it's not that interesting. In the GCC version,
> you get some extra optimizations that are not possible in the sizeof
> division. (In cases of VLAs, which maybe are not used in groff; I
> don't know.)
We don't, at least not in the C99 sense.
INSTALL.extra:
A few components of groff are written in ISO C99. Features later
made optional by ISO C11 (the 'complex' primitive data type and
variable-length arrays) are not used.
> A more interesting feature is in the works: using countof() on array
> parameters. This needs compiler magic:
>
> void
> foo(size_t n, int a[n])
> {
> for (size_t i = 0; i < _Countof(a); i++)
> a[i] = 0;
> }
>
> I've implemented this for GCC, but a few corner cases still need work.
> Essentially, I need to implement some diagnostics to prevent stupid
> things. This is being discussed in the C Committee too, although I
> don't want to formally propose it for standardization before having it
> in GCC.
>
> I expect this will be ready in GCC 17.
Cool! Ritchie's rolling over in his grave to see C approaching full
language support for container iterators like this. :P
> > Maybe this patch series should be updated and filed as a bug so this
> > refactoring doesn't get forgotten. Maybe bug #66518 could depend on
> > it.
>
> Nah; I can ping you. For patches, the mailing list is much easier to
> me.
Works for me!
Regards,
Branden
signature.asc
Description: PGP signature
