Hi Branden,

On Thu, Sep 18, 2025 at 03:19:52PM -0500, G. Branden Robinson wrote:
> Hi Alex,
> 
> At 2025-09-17T14:44:23+0200, Alejandro Colomar wrote:
> > Ping.
> > 
> > I'm also working on having some other APIs added to gnulib, so I'll
> > send more patches eventually (once they do the next stable release,
> > with these new APIs).
> 
> 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.  :)

> 2.  My impression is that `countof()` is available only in that stable
>     tag, not the 2025-01 one we're currently on.  (I have been very lazy
>     here, and not looked.)

Yep; countof() is available since 202507 (IIRC).

> 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.

-  It removes maintenance burden from groff(1), since it's maintained by
   gnulib.

If you need me to rebase on top of your changes to reduce your work
applying, I can do that.

> 4.  I'm trying to fry release-critical fish.  Assuming Deri doesn't find
>     a problem with my overhauled and heavily unit-tested refactoring of
>     "asciification"[2][3]--which, knock wood, will make hyperlink text
>     construction and PDF bookmarking much easier in _any_ macro
>     package--then I need to sort out the problem of underspecified
>     delimiter semantics.[4][5]  CSTR #54 kind of whistled past the
>     graveyard here;[6] zombies have finally erupted to stalk the night.
> 
> 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.)

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.

> 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.


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

Attachment: signature.asc
Description: PGP signature

Reply via email to