Re: [PATCH v1 1/2] [troff]: Add lengthof() macro.

[G. Branden Robinson]

Hi Alex,

At 2023-08-26T00:55:16+0200, Alejandro Colomar wrote:
> The good news is that I like the implementation.  I just don't like the
> name.  I have a sizeof_array() macro that does
> 
> #define sizeof_array(a)  (sizeof(a) + must_be_array(a))
> 
> That is, it calculates the size in bytes that the array takes up in
> memory.
> 
> <https://github.com/shadow-maint/shadow/pull/762/commits/8d06d849dcb5f7041e048d866ec7ce6c1853245b>
> 
> For a macro that returns the number of elements in an array, I'd like
> a name that cannot be confused with that at all.  NELEMS(), NITEMS(),
> array_count(), or lengthof() all seem better than array_size().

This is a sensible enough objection.  I'm renaming it to "array_length".
I want to keep "array_" in the name because it works only with array
types.  I admit it's possible that C++ could do shocking DWIM things
under the hood to coerce non-array types to work with the template, but
testing suggests that this is not the case...

../src/preproc/eqn/box.cpp:133:39: error: no matching function for call to 
‘array_length(int&)’
  133 | static size_t len = array_length(errno);
      |                                       ^
In file included from ../src/preproc/eqn/eqn.h:19,
                 from ../src/preproc/eqn/box.cpp:21:
../src/include/lib.h:158:8: note: candidate: ‘template<class T, long unsigned 
int N> size_t array_length(T (&)[N])’
  158 | size_t array_length(T(&)[N]) {
      |        ^~~~~~~~~~~~
../src/include/lib.h:158:8: note:   template argument deduction/substitution 
failed:
../src/preproc/eqn/box.cpp:133:39: note:   mismatched types ‘T [N]’ and ‘int’
  133 | static size_t len = array_length(errno);
      |                                       ^

> I'm not a fan of lengthof(), even if it's a proposal to ISO C, as so
> far the term "length" was only the number of non-zero characters in a
> string,

I submit to you that this is an example of C programmers' parochialism.
Character arrays have outsized importance to practitioners of that
language, in part because C was applied to the problem domain of text
processing before it had to mature features to support that application.

(One might find that an audacious claim given the software that is the
topic of this mailing list.  I remind the reader that, on Unix, roff and
nroff were written in assembly language first.)

Further, you and I have spoken before of the Shlemiel the Painter
problems to which users of string.h are prone.

I submit that a language with even a moderately strong type system
ineluctably implies the existence and application of collections of
objects of those type.  "Length" is not a concept that `char[]` should
be permitted to monopolize from a bunker.

> NITEMS() or NELEMS() seems the best choice to me.

I don't like these very much because (a) they're not English words and
(b) they shout.  I concede that there are reasons, in C (cf. C++) to
shout function-like macro names.  Rust's `!` suffix is a nice idea.

> I had a similar complaint to this one to kernel people, which were
> even more evil than you,

I am wounded that you regard my capacity for evil as meager. :P

> and having a macro ARRAY_SIZE() that returns the number of elements,
> later added a function array_size() that returns the size of a
> (dynamic) array in bytes.  I'd like you to avoid being evil.
> 
> <https://lore.kernel.org/lkml/57a30a95-b63c-7ad4-070f-db70262b6b7c@kernel.org/>

There's good evil and bad evil.  Don't confuse them!  ;-)

[Linux kernel stuff trimmed]

> >> I added it there because I didn't find a "common utilities" header
> >> file.  Please suggest a better place.
> > 
> > I put it in src/include/lib.h.
> 
> Ok.  I'll consider it for similarly generic stuff.
> 
> > At 2023-08-04T15:40:30+0200, Alejandro Colomar wrote:
> >> In C++17, I'd just call std::size().
> >>
> >> In C11 (or C++11), I'd add a static_assert(3) to that macro to make
> >> it safer (but compiler warnings already make it reasonably
> >> safe[1]).
> >>
> >> In a mix of C++98 / C99, there's nothing I know of.  We could use
> >> templates, which is how I bet std::size() is implemented, but I
> >> don't have enough experience with them to do this kind of magic.

Incidentally, this was a valuable summary of the language's history.
I have a pending commit to the "HACKING" file informed by this.

> > But I think want to understand the C++98 ships in the harbor a bit
> > before I burn the fleet.
> 
> I'll send some C99 ships to try to convince you to get on board with
> their brand new sails --pure cotton, or 99%--.

I like C99 fine.  It's just not the language that (most of) groff is
written in, and were I to undertake a ground-up replacement, I'd use a
language I like more (albeit with an FFI with C/C++).

Regards,
Branden

signature.asc
Description: PGP signature