Deutsch English Français Italiano |
<85h635jatg.fsf@nosuchdomain.example.com> View for Bookmarking (what is this?) Look up another Usenet article |
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 */