Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: James Kuyper <jameskuyper@alumni.caltech.edu>
Newsgroups: comp.lang.c
Subject: Re: Results of survey re. a new array size operator
Date: Wed, 29 Jan 2025 11:09:39 -0500
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <vndk9r$2etm7$1@dont-email.me>
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=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 29 Jan 2025 17:17:00 +0100 (CET)
Injection-Info: dont-email.me; posting-host="e59222cea81c02a60565b290ef11bf7a";
	logging-data="2586311"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19ao7HPdUTwQph4g4xc8pZk+fXzhzwYuV4="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:4U3OV2M+TQau8TkqwG3o+n/hy2g=
Content-Language: en-US
In-Reply-To: <vnd4db$2bqlb$2@dont-email.me>
Bytes: 3182

On Wed, 29 Jan 2025 11:45:47 +0000
bart <bc@freeuk.com> wrote:

> On 29/01/2025 09:48, Tim Rentsch wrote:
....
> > 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)


The semantics of the "->" operator specify that

"The value is that of the named member of the object to which the first
expression points..."  (6.5.2.3p4).

There can be no such object, because

"... a null pointer, is guaranteed to compare unequal to a pointer to
any object ..." (6.3.2.3p3).

Since there is no explicitly defined behavior for such an expression,
the behavior is implicitly undefined. On many platforms it will work
exactly as you expect, but not all.

Even on platforms where that part works, this code relies upon the
assumption that the result of that conversion will be the distance from
the beginning of the struct to the start of the specified object. That
seems to be based upon the assumption that a null pointer points at
address 0, and that addresses increase by one for each byte in the
object, and that the conversion to size_t converts a pointer value into
the corresponding address. All of those assumptions are valid on many
platforms, but none of them are guaranteed by the standard. "Any pointer
type may be converted to an integer type. Except as previously
specified, the result is implementation-defined." (6.3.2.3p6). So this
definition for the offsetof() macro, while a valid one on many
platforms, is not standard C.

That's why offsetof() is a standard macro with implementation-specific
expansion - on many platforms, the above expansion won't work.