Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Thu, 03 Apr 2025 12:37:31 -0700
Organization: None to speak of
Lines: 60
Message-ID: <85h635jatg.fsf@nosuchdomain.example.com>
References: <87y0wjaysg.fsf@gmail.com> <vsj1m8$1f8h2$1@dont-email.me>
	<vsj2l9$1j0as$1@dont-email.me> <vsjef3$1u4nk$1@dont-email.me>
	<vsjg6t$20pdb$1@dont-email.me> <vsjjd1$23ukt$1@dont-email.me>
	<vsjkvb$25mtg$1@dont-email.me> <vsjlkq$230a5$2@dont-email.me>
	<vsjs5k$2bfc5$2@dont-email.me> <vsjvgu$2fpp1$1@dont-email.me>
	<GDfHP.1440068$SZca.528582@fx13.iad> <86semphp2p.fsf@linuxsc.com>
	<GnwHP.5713$j2D.3280@fx09.iad>
	<85plhtjd5k.fsf@nosuchdomain.example.com>
	<QPAHP.1158307$2zn8.802132@fx15.iad>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Thu, 03 Apr 2025 21:37:32 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="658736fab9029f452335cecd036b8387";
	logging-data="1367561"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+HAfFh2guwEGocpAj2dASX"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:SJgwauuWJnSXmcYwLIc2Z6YPH38=
	sha1:/eAH2SFmW2PMb8l4XBtDa5+Q3/Q=
Bytes: 3741

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.
>>
>>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.
>
> So, if unix/linux system header files are posix compliant, they're
> technically not completely compliant with the C standard, although
> they will compile code that complies with the C standard.

An implementation can be both C compliant and POSIX compliant by
ignoring that extension.  POSIX doesn't *require* inclusion of
<string.h> to include <stddef.h>.

But an implementation that does do that does not conform to the C
standard, since it will reject the following valid C code:

    #include <string.h>
    int wchar_t = 0;

(Unless the diagnostic is a non-fatal warning, I suppose, or unless
<string.h> makes wchar_t visible only if _POSIX_C_SOURCE is defined,
but why bother?)

To be clear, I'm not suggesting that defining wchar_t for your own
purpose is a good idea.

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