Re: "A diagram of C23 basic types"

On 03/04/2025 02:41, Keith Thompson wrote:

scott@slp53.sl.home (Scott Lurndal) writes:

bart <bc@freeuk.com> writes:

On 02/04/2025 18:29, David Brown wrote:

On 02/04/2025 17:38, bart wrote:

[...]

You also need to include some header (which one?) in order to use it.

>
<stddef.h>, as pretty much any C programmer will know.

>
This program:
>
   void* p = NULL;
>
reports that NULL is undefined, but that can be fixed by including any
of stdio.h, stdlib.h or string.h. Those are the first three I tried;
there may be others.
>
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.

>
Indeed, and it is well documented.
>
For example, in the POSIX description for the string functions you'll
find the following statement:
       [CX] Inclusion of the <string.h> header may also make visible all
          symbols from <stddef.h>. [Option End]
>
This is true for a number of POSIX headers, include those you enumerate
above.
>
[CX] marks a POSIX extension to ISO C.

 Interesting.  The C standard says that <string.h> defines NULL and
size_t, both of which are also defined in <stddef.h>.  A number of other
symbols from <stddef.h> are also defined in other headers.  A conforming
implementation may not make any other declarations from <stddef.h>
visible as a result of including <string.h>.  I wonder why POSIX has
that "extension".
 

The documentation quoted by Scott says "may".  To me, it seems pretty obvious why they have this.  It means that their definition of <string.h> can start with
#include <stddef.h>
rather than go through the merry dance of conditional compilation, defining and undefining these macros, "__null_is_defined" macros, and the rest of it.  This all gets particularly messy when some standard headers (generally those that are part of "freestanding" C - including <stddef.h>) often come with the compiler, while other parts (like <string.h>) generally come with the library.  On some systems, these two parts are from entirely separate groups, and may use different conventions for their various "__is_defined" tag macros.
But by writing "may", it is clear that some setups may define the identifiers solely according to the C standards documentation.  Thus you should not rely on an inclusion of <string.h> providing the "offsetof" macro - but equally, you should not rely on it /not/ providing that macro.