Re: "A diagram of C23 basic types"

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

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>

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

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>

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

bart <bc@freeuk.com> writes:

>
[...]
>

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.

>
How strange.  I don't know why anyone would ever want either to
rely on or to take advantage of this property.

>
Some existing unix implementations at the time the standard was
adopted had that behavior and the committee was not willing to
break existing implementations.

A shortsighted decision IMO, because it weakens confidence in the
POSIX standard.  Also the use of "break" there is odd, since
those implementations were already broken.

You mean the POSIX standard, yes?  The C standard does not permit
<string.h> to include <stddef.h>.

>
Yes, and POSIX explictly marks it as an extension to the C
standard.

Strictly speaking it is not an extension as the C standard uses
the term, because extensions are allowed only if they don't
change the behavior of any strictly conforming program, and
making <stddef.h> symbols visible due to #include <string.h>
doesn't satisfy that condition.