Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: "A diagram of C23 basic types" Date: Thu, 03 Apr 2025 03:27:21 -0700 Organization: None to speak of Lines: 66 Message-ID: <85ecy9leuu.fsf@nosuchdomain.example.com> References: <87y0wjaysg.fsf@gmail.com> <85ecya5b68.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Thu, 03 Apr 2025 12:27:22 +0200 (CEST) Injection-Info: dont-email.me; posting-host="658736fab9029f452335cecd036b8387"; logging-data="416555"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18iZeOFgDrCAM0ENvIy/cXJ" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:TGRbA9CVLv3kWMgWlCXQxHn6Ja0= sha1:ju4fZ9Tqn2RM76jjgO1lVFUNpoA= Xref: csiph.com comp.lang.c:391904 David Brown 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 header may also make >>> visible all >>> symbols from . [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 defines NULL and >> size_t, both of which are also defined in . A number of other >> symbols from are also defined in other headers. A conforming >> implementation may not make any other declarations from >> visible as a result of including . 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 > can start with > > #include > > 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 > ) often come with the compiler, while other parts (like > ) 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 providing the > "offsetof" macro - but equally, you should not rely on it /not/ > providing that macro. The ISO C standard guarantees that including 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 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 */