Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Thu, 3 Apr 2025 10:23:40 +0200
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <vslgic$6ifr$1@dont-email.me>
References: <87y0wjaysg.fsf@gmail.com> <vsj1m8$1f8h2$1@dont-email.me>
 <vsj2l9$1j0as$1@dont-email.me> <vsjef3$1u4nk$1@dont-email.me>
 <vsjg6t$20pdb$1@dont-email.me> <vsjjd1$23ukt$1@dont-email.me>
 <vsjkvb$25mtg$1@dont-email.me> <vsjlkq$230a5$2@dont-email.me>
 <vsjs5k$2bfc5$2@dont-email.me> <vsjvgu$2fpp1$1@dont-email.me>
 <20250402113624.693@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 03 Apr 2025 10:23:41 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d65639e364606db0746acbec737df138";
	logging-data="215547"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+53ZVtTu16sbrg9U/UltWfl5p7Vc9sdNA="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:F+OW6+W4uvQLpiTa8StnsrELOX8=
Content-Language: en-GB
In-Reply-To: <20250402113624.693@kylheku.com>
Bytes: 3901

On 02/04/2025 20:51, Kaz Kylheku wrote:
> On 2025-04-02, bart <bc@freeuk.com> wrote:
>> So it is not true that you need include stddef.h, nor obvious that that
>> is where NULL is defined, if you are used to having it available indirectly.
> 
> It's documented as the canonical source of NULL.
> 
> In C90, now 35 years ago, it was written up like this:
> 
>    7.1.6 Common definitions <stddef.h>
> 
>      The following types and macros are defined in the standard header
>    <stddef.h>.  Some are also defined in other headers, as noted in their
>    respective subclauses.
> 
>    ...
> 
>       The macros are
> 
>           NULL
>    which expands to an implementation-defined null pointer constant: and
>   
>           offsetof(type, member-designator)
> 
>    ... etc
> 
> There is no other easy way to find that out. An implementation could directly
> stick #define NULL into every header that is either allowed or required to
> reveal that macro, and so from that you would not know which headers are
> required to provide it.
> 
> Many things are not going to be "obvious" if you don't use documentation.
> 
> (In my opinion, things would be better if headers were not allowed to behave as
> if they include other headers, or provide identifiers also given in other
> heards. Not in ISO C, and not in POSIX.  Every identifier should be declared in
> exactly one home header, and no other header should provide that definition.
> Programs ported from one Unix to another sometimes break for no other reason
> than this! On the original platform, a header provided a certain identifier
> which it is not required to; on the new platform that same header doesn't do
> that.)
> 

IMHO, it would be better if headers were explicitly defined as including 
other headers.  The documentation of <string.h> should say that it 
includes <stddef.h>.  That way everything is defined in one and only one 
header, in a clear manner, without forcing users to manually include 
extra headers in a specific order.

In particular, since <stddef.h> contains "common definitions", it would 
be natural to say that /all/ standard library headers include it.  That 
would simplify implementations, and simplify the standards documents, 
and I would be very surprised if it lead to any real code conflicts.

After that, there are only a few cases where one standard library header 
would need to include another one - such as <inttypes.h> including 
<stdint.h>.