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

On 30/01/2025 01:31, Ben Bacarisse wrote:

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.
 

Agreed.
I have yet to see a serious example of VLA use where the evaluation of the operand is actually relevant - I don't count VLA declarations of size "rand()" as realistic.
It is possible to construct an example where a macro akin to his SIZE_KEYWORD could result in a double evaluation when a VLA is used. But you have to try harder than the blog author did.  For example :
int foo(int n) {
int meow[3][4][n];
return SIZE_KEYWORD(meow[first_idx()]);
}
I needed a three dimensional VLA to get a double evaluation of first_idx().
His type-safety argument is a lot stronger IMHO.  Simple "ARRAY_SIZE" macros are happy with some pointers rather than requiring arrays, while a language operator would give compile-time errors if you made a mistake like :
int foo(int arr[]) {
size_t n = ARRAY_SIZE(arr);
...
gcc (and presumably other compilers) can warn about at least some such code errors, and gcc extensions let you write a more advanced ARRAY_SIZE like the one defined in Linux.
IMHO a more useful approach would have been to standardise the gcc extension used to make the Linux macro (__builtin_types_compatible_p). This can be useful in many other circumstances.  Then it could be used in a macro defined in a standard header for the C library so that other programmers don't have to figure it out for themselves.  And it should be "cheaper" to add a new standard header and a macro than a new keyword, with less potential for conflict with existing code.
(I believe there are a variety of other ways to make a safe array_size macro using gcc extensions.)