Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Results of survey re. a new array size operator
Date: Tue, 18 Feb 2025 19:46:48 -0800
Organization: A noiseless patient Spider
Lines: 90
Message-ID: <86v7t6y4t3.fsf@linuxsc.com>
References: <87a5bgsnql.fsf@gmail.com> <87ldut38zt.fsf@bsb.me.uk> <vndmsc$2fau5$1@dont-email.me> <87frl12lce.fsf@bsb.me.uk> <86v7twysa0.fsf@linuxsc.com> <UeSmP.63220$HO1.11976@fx14.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Wed, 19 Feb 2025 04:46:49 +0100 (CET)
Injection-Info: dont-email.me; posting-host="69e9ac3a61d8883cfaa10bb46c2a312b";
	logging-data="2098247"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/h1HH5aPm6/PcGqW1KLFJM6HOJdSn9teo="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:HNhH1ks7P3Zj4l3PapuEUWs724Q=
	sha1:zSPKnBBDJH319/dWXxk2tlcwoPY=
Bytes: 5046

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.