Re: "A diagram of C23 basic types"

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

In ISO C, this:

    #include <string.h>
    wchar_t w = L'w';

is a constraint violation, and this:

    #include <string.h>
    int wchar_t = 42;
    int main(void){}

is, I believe, strictly conforming.

gcc with glibc on Ubuntu does not implement that extension.
gcc with newlib on Windows/Cygwin does.  Presumably this is an artifact
of the way the respective string.h files are written, having nothing
directly to do with the compiler.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */