Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: Results of survey re. a new array size operator
Date: Wed, 29 Jan 2025 14:24:30 +0200
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <20250129142430.0000544b@yahoo.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
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 29 Jan 2025 13:24:32 +0100 (CET)
Injection-Info: dont-email.me; posting-host="d4e02a1b8e0e79ca6ce2034275816a21";
	logging-data="1960013"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18UKPzX5JKIa9oU73jpaJbiCLugDAfJFlk="
Cancel-Lock: sha1:MeyAZe63Qp2jmyMmxqyYrXU7oJU=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 3243

On Wed, 29 Jan 2025 11:45:47 +0000
bart <bc@freeuk.com> 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)
> 

A magic of Standard Library, which is above UB rules of mortals.
The macro like above is blessed as long as it resides in stddef.h, but
damned in nonstddef.h.

OTOH, '#define ARRAY_LEN (sizeof((x))/sizeof((x)[0]))' is o.k.
everywhere.