Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: Results of survey re. a new array size operator
Date: Fri, 24 Jan 2025 20:10:10 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 107
Message-ID: <20250124115250.760@kylheku.com>
References: <87a5bgsnql.fsf@gmail.com> <20250124135623.00004479@yahoo.com>
 <QgNkP.76380$ZEZf.54113@fx40.iad>
Injection-Date: Fri, 24 Jan 2025 21:10:10 +0100 (CET)
Injection-Info: dont-email.me; posting-host="7f33a37540ba8b226dd6885cb0d9398b";
	logging-data="2502239"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+OY/zebU+U+VeTgt7ggX4FvcB+m+j/j9w="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:UfpG5YJe+KBCYCmxRMQXaxRDAi0=
Bytes: 4829

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