Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Fri, 04 Apr 2025 03:27:06 -0700
Organization: A noiseless patient Spider
Lines: 53
Message-ID: <867c40gr2d.fsf@linuxsc.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; charset=us-ascii
Injection-Date: Fri, 04 Apr 2025 12:27:07 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0b7dfe457c74e7e4c87a6e88750aefc9";
	logging-data="3317211"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19zE7esGKWZz3cM4m4Q3aJMSTYwNkfYrVI="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:P+O5YuW/M+stF99jGcsgkk/7qTI=
	sha1:Z7VxSPpFOj63yO1mz3iICfmi/dE=
Bytes: 3329

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.