Re: "A diagram of C23 basic types"

David Brown <david.brown@hesbynett.no> writes:

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

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

[...]

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.

Yes, implementers *may* be so lazy that they don't bother to define
their standard headers in the manner required by the C standard.

Building an implementation from separate parts can make things more
difficult.  That's no excuse for getting things wrong.

Maybe you could have an implementation that conforms to POSIX without
attempting to conform to ISO C, but POSIX is based on ISO C.

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.

The ISO C standard guarantees that including <string.h> does not define
"wchar_t".  Cygwin newlib violates this guarantee.  In fact the
implementation (gcc with newlib) violates POSIX as well, by defining
wchar_t when no feature test macros are defined.

$ cat c.c
#include <string.h>
int wchar_t = 0;
$ gcc -std=c17 -pedantic -c c.c
c.c:2:5: error: ‘wchar_t’ redeclared as different kind of symbol
...

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