Hi Branden, On Thu, Sep 18, 2025 at 04:32:34PM -0500, G. Branden Robinson wrote: > 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
Heh! There's still people in the C Committee that doesn't like them.
Some false purists thinks that only system calls and other magic
functions should be in the standard, and that convenience functions
should go in external libraries (that would exclude every string.h
function from libc except for memset(3) because of its magic aliasing
properties; insane, IMO). Some others just think libc functions should
have some complexity; adding simple wrappers seemingly doesn't make them
feel proud of inventing useless crap; it doesn't make them look smart.
The committee is really something out of a comedy. And there are
others. I could tell stories...
Ironically, they added memccpy(3) in C23, and it has 0 users in the real
world. That one was probably introduced because it made the committee
look smart, because they arrived first at discovering a function they
thought useful (hint: it's not). Too bad that memccpy(3) is as
dangerous as strncpy(3). Will they ever realize it has no users and
that they promoted a function that is unsafe and now starts being used
by innocent programmers? Probably not; that's a problem for the next
generation of committee members; they'll retire before the fallout.
> wonder by how many orders of magnitude string (in)equality comparisons
> exceed string collation order comparisons.
I have numbers in my laptop. I developed a patch for glibc adding these
APIs and then replacing every possible use within glibc itself. When
I use my laptop tomorrow, I can check the remaining strcmp() calls
compared to streq(). I remember having looked at the ratio, but don't
remember the numbers. I think it was in the hundreds of equality calls
per each sorting call.
> > > 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. :)
Well; even during the initial period, the unfamiliarity isn't worse than
inventing your own name. After all, you need to invent a name. :)
> I don't disagree with the migration; it just seems like an "eventually"
> thing to me.
If you have some window of time where you'd apply it, I can have the
patch ready for that window. I guess once you decide to apply it it's
a matter of running git-am(1), and forgetting about it. It should be
a moment when your local queue of patches is small, to reduce your
rebasing work. But being a trivial (yet large) patch, it's not
something I see very problematic. The major blocker is bumping gnulib;
just let me know when you'll do that.
> > - 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
Actually, I think this is something that was originally devised by K&R,
and I'm just filling the gaps. I can't see another reason they allowed
using array notation in parameters, if they didn't want them to behave
like that.
I'm curious about what K has to say about this feature, if he would know
about it.
> > > 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!
Cheers,
Alex
--
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).
signature.asc
Description: PGP signature
