Re: Results of survey re. a new array size operator

scott@slp53.sl.home (Scott Lurndal) writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>

Ben Bacarisse <ben@bsb.me.uk> writes:
>

David Brown <david.brown@hesbynett.no> writes:
>

On 29/01/2025 17:00, Ben Bacarisse wrote:
>

Alexis <flexibeast@gmail.com> writes:
>

JeanHeyd Meneide, a Project Editor for WG14, has just posted the
results of a survey re.  the preferred form of a new array size
operator:
>
-- https://thephd.dev/the-big-array-size-survey-for-c-results

>
Curious.  The top objection to the usual macro solution is given
as:
   * double-evaluation of e.g. getting the size of the 1-d part of
     a 2-d array
     int meow[3][4]; /* ... */ SIZE_KEYWORD(meow[first_idx()]);
Does the author not know that there is no evaluation of the
operands of sizeof in this example?

>
6.5.3.4p2 :
>
"""
If the type of the operand is a variable length array type, the
operand is evaluated;  otherwise, the operand is not evaluated and
the result is an integer constant.
"""
>
I don't know if that is the source of the double-evaluation concern
here, but it is certainly a situation in which sizeof /does/
evaluate its operand.

>
It would have been a good idea to pick an example that behaves as
claimed.  Let's hope this sort of casual approach is reserved for
blogs.

>
All of the motivational examples listed are lame.  Everyone knows
that macro calls might evaluate an argument twice, and so to avoid
calling macros on expressions with side-effects.  It's true that
the usual macro definition to determine array extent misbehaves
but that can simply be called out as a warning without needing to
codify the situation by putting it in the C standard;  in other
words it's a quality of implementation issue, not a language issue
(and some cases are already diagnosed by both gcc and clang).  As
for the problem of name collision, choosing a longer name and
having it be all caps (as most macro names should be) gives a
collision cross section that is vanishingly small.  Either of the
names ARRAY_INDEX_LIMIT() or ARRAY_EXTENT() are both descriptive
enough and unlikely-to-collide enough that they can be used
without any significant danger of collision.
>
What would be better is to give some general tools that would
allow a user-defined macro to be written safely.  For example:
>
  _Has_array_type( e )       1 if and only if the expression
                             'e' has array type
>
  _Is_side_effect_free( e )  1 if and only if the expression
                             'e' has no side effects, so
                             multiple evaluations have no
                             negative consequences
>
Furthermore because these tests are likely to be called only
inside macro definitions, using the _Leading_capital style of
naming shouldn't be a problem.

>
Seems like a lot of cruft just to save a small bit of
typing by the programmer.
>
The decades old standard idiom of sizeof(x)/sizeof(x[0])
is self-documenting and requires no macros or new language
features.

Speaking for myself personally, I don't mind using the common
idiom (although I consider it better practice to write a macro
for it, but that is a minor point), and consider the proposal
to add a new language construct to the C standard to be worse
than simply a waste of time.

The point of my earlier comment is that, if something is going to
be added to the C standard, it would be better if what were added
provided some generality so it could be used for more than just
the number of elements in an array.  An endless series of special
cases is anathema to good language design.