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

On 2025-01-24, Scott Lurndal <scott@slp53.sl.home> wrote:

Michael S <already5chosen@yahoo.com> writes:

On Fri, 24 Jan 2025 17:57:22 +1100
Alexis <flexibeast@gmail.com> wrote:
>

Hi all,
=20
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:
=20
"There is a clear preference for a lowercase keyword, here, though it
is not by the biggest margin. One would imagine that with the way we
keep standardizing things since C89 (starting with _Keyword and then
adding a header with a macro) that C folks would be overwhelmingly in
favor of simply continuing that style. The graph here, however, tells
a different story: while there=E2=80=99s a large contingency that clearly
hates having _Keyword by itself, it=E2=80=99s not the _Keyword + stdkeywo=

rd.h

macro that comes out on top! It=E2=80=99s just having a plain lowercase
keyword, instead."
=20
-- https://thephd.dev/the-big-array-size-survey-for-c-results
=20
=20
Alexis.

>
Majority is wrong. What's new?=20

>
Actually, the entire article is bogus.  There's no need for
some new keyword to replace the code that's been  used for
half a century to size a statically allocated array.
>
Using the phrase 'debate perverts' in an attempt to deflect
criticism pretty much eliminates authorial credibility.
>
   int arfarf[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
   return sizeof(arfarf) / sizeof(arfarf[0]);

You can define

  #define arraysize (x) (sizeof (x) / sizeof ((x)[0))

the only problem is that this bug sometimes happens:

  arraysize (ptr)

however, this can be diagnosed. A compiler can look
for occurrences of a match for the abstract syntax
tree pattern:

  (sizeof (x) / sizeof (*(x) + 0)

where x is other than an array type, and issue a warning.

$ cat > arraysize.c
#include <stdio.h>

int main(int argc, char **argv)
{
    printf("array size of argv, wrong = %zd\n",
           sizeof (argv) / sizeof (argv[0]));
    return 0;
}
$ make CFLAGS="-Wall -W -O2" arraysize
cc -Wall -W -O2    arraysize.c   -o arraysize
arraysize.c: In function 'main':
arraysize.c:6:26: warning: division 'sizeof (char **) / sizeof (char *)' does not compute the number of array elements [-Wsizeof-pointer-div]
    6 |            sizeof (argv) / sizeof (argv[0]));
      |                          ^
arraysize.c:3:27: note: first 'sizeof' operand was declared here
    3 | int main(int argc, char **argv)
      |                    ~~~~~~~^~~~
arraysize.c:3:14: warning: unused parameter 'argc' [-Wunused-parameter]
    3 | int main(int argc, char **argv)
      |          ~~~~^~~~


Thus, this is a solved problem, except for everyone reinventing
their own name for the array size macro.

It was enough of a problem for everyone reinventing their own name
for a 32 bit unsigned integer that we got uint32_t.

I'd be in favor of <sttddef.h> incorporating an arraysize
macro similar to how it has offsetof.

This macro definition would be hidden unless the compiler operator
selects a the dialect of C where that has become available,
or newer.

The standard can have a footnote encouraging implementors to
diagnose sizeof (ptr) / sizeof (ptr[0]).

It could be a constraint violation in the division operator, e.g.

  Constraints [ proposed ]
  ...
  When the left operand of / is an expression of the form sizeof expr, or
  sizeof (type), where the size obtained of a type pointer to T,
  the right operand shall not be an expression of the form sizeof expr
  or sizeof (type), where the size obtained is of a type T.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca