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:01:13 -0800
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <868qqt1ueu.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> <cfdddf87033f99d80581e129d9a4ac5d983f2f3a@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Wed, 29 Jan 2025 17:01:14 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ba8d9ca2da4b9314498ee7469992f70e";
	logging-data="2572767"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+cUafkXOZRrffBC8r8caMkk5oo3W9AD84="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:j0WglXI837yVtY0DCc+OB2PXMfE=
	sha1:uCmw1pzlxzSVWQEHxTh6mdYGPhM=
Bytes: 3793

Richard Damon <richard@damon-family.org> writes:

> On 1/29/25 6:45 AM, bart wrote:
>
>> 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)
>
> Which has undefined behavior, the deferencing of a null pointer.
>
> Only if the implementation defines that behavior to be what we want,
> can that be done.  Most implementtions, that sort of behavior turns
> out to work out, but it isn't mandated by the Standard.

Undefined behavior of the pointer dereference isn't the only
problem.  Whatever comes out of the offsetof() macro has to be an
integer constant expression.  To do that, the implementation needs
to take advantage of the provision in 6.6 p10 that allows an
implementation to accept other forms of constant expressions.  In
fact the particular case of offsetof() taking advantage of this
provision, to create an integer constant expression, has been
confirmed in a response to a Defect Report (sorry, I don't remember
which one).