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: Wed, 29 Jan 2025 08:18:18 -0800
Organization: A noiseless patient Spider
Lines: 83
Message-ID: <864j1h1tmd.fsf@linuxsc.com>
References: <87a5bgsnql.fsf@gmail.com> <20250124135623.00004479@yahoo.com> <QgNkP.76380$ZEZf.54113@fx40.iad> <20250124115250.760@kylheku.com> <afUkP.928261$2xE6.342839@fx18.iad> <20250124165243.678@kylheku.com> <868qqu2bnl.fsf@linuxsc.com> <vnd4db$2bqlb$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Wed, 29 Jan 2025 17:18:18 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ba8d9ca2da4b9314498ee7469992f70e";
	logging-data="2572767"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+M8QOy+5iVxDfzXXwoH/rbxVEc9StteIw="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:h7wCXbiij5PNUI9EuVjYqNJS+lo=
	sha1:jQozhqmN1r73CyZcASq/ZIHpV9I=
Bytes: 4334

bart <bc@freeuk.com> writes:

> On 29/01/2025 09:48, Tim Rentsch wrote:
>
>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>
>>> On 2025-01-24, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>
>>>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>>>
>>>>> On 2025-01-24, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>>> You can define
>>>>>
>>>>>   #define arraysize (x) (sizeof (x) / sizeof ((x)[0))
>>>>
>>>> You can, but you don't need to.
>>>
>>> The repetition in things like:
>>>
>>>    sizeof foo->bar.buf / *sizeof foo->bar.buf
>>>
>>> is just irksome.  Why do I have to say that thing twice,
>>> to get its number of elements?
>>>
>>>> Often readability suffers
>>>> when you use macros, not to mention the other quirks of
>>>> C macro use (in C++, a constexpr function might be
>>>> suitable, but the naming being arbitrary (e.g. arraysize,
>>>> NUM_ELEMENTS, SIZE, et alia) doesn't aid in readability
>>>> or maintainability.
>>>
>>> The naming being arbitrary is the argument for standardizing the
>>> name for the macro and sticking it into, for instance, <stddef.h>.
>>>
>>> If we didn't have offsetof there, we might have to deal with
>>> OFFSETOF, offsetof, offset, member_offset, and others.
>>
>> That's a flawed analogy.  A macro to compute the number of
>> elements in an array can be done in standard C.  The
>> functionality of offsetof cannot be done in standard C, and
>> that's what it needs to be in the standard library.
>
> Can't it?  The various versions I've seen, including mine, look
> like this:
>
>   #define offsetof(a,b) (size_t) &( ((a*)0) -> b)

That form of expression is not guaranteed to work, as other
responses have explained.

> As for the other point that was made, when looking at open source
> code, every other program seems to contain macros like
>
>   MAX
>   ARRAYLEN
>   STREQ
>
> But with assorted spellings (the first program I looked at today used
> MZ_MAX).
>
> However, every other program also seems to use typedefs to define
> their own versions of INT32 etc, even with stdint.h type being
> available for 25 years.

Probably historical baggage.  It was ten years after C89 that C99
added <stdint.h>, and probably five more years before people
started using C99 regularly.  And it didn't help that Microsoft,
in their near-infinite wisdom, didn't ever really support C99,
and waited until C11 before doing an implementation conforming to
a current C standard.  So the pre-C99 names had many years to
become entrenched, and after that there was no sufficiently
motivating reason to change them.  If it ain't broke don't fix
it.

> So being in the standard is not enough if the official name is
> too ugly or it is fiddly to type.

Personally I think the type names added in <stdint.h> are both
ugly and almost always a bad choice for other reasons.  That
said, I note that uint32_t and uint64_t have become nearly
ubiquitous (and also uint8_t, which is completely baffling, since
unsigned char can be used instead, along with some form of static
assertion for people who are overly obsessive).