Re: "A diagram of C23 basic types"

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>.