Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: VAX Date: Mon, 15 Dec 2025 11:51:43 -0800 Organization: A noiseless patient Spider Lines: 33 Message-ID: <865xa7ttf4.fsf@linuxsc.com> References: <0c857b8347f07f3a0ca61c403d0a8711@www.novabbs.com> <2025Jul30.075918@mips.complang.tuwien.ac.at> <2025Aug1.191648@mips.complang.tuwien.ac.at> <106jvc3$qan0$1@dont-email.me> <106kh0k$18ipb$1@paganini.bofh.team> <2025Aug3.185110@mips.complang.tuwien.ac.at> <106otf6$1sov2$1@dont-email.me> <106p4k6$1u13o$1@dont-email.me> <20250804121938.0000122a@yahoo.com> <2025Aug4.140932@mips.complang.tuwien.ac.at> <2025Aug4.165141@mips.complang.tuwien.ac.at> <20250804182839.00000600@yahoo.com> <87sei7do4g.fsf@example.invalid> <20250804220315.00007240@yahoo.com> <6859dc0d-f3b5-481b-8ffb-b4c0a722412e@alumni.caltech.edu> <20250804224049.00006937@yahoo.com> <87ldny7397.fsf@example.invalid> <20250805141510.761@kylheku.com> <106vtuk$2uli0$2@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Mon, 15 Dec 2025 19:51:45 +0000 (UTC) Injection-Info: dont-email.me; posting-host="3b66f75cc16331490dd39d06d7ef9603"; logging-data="2231266"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX184jZIOmWt7xhj5+eXZLNO03U6RVYkbKkY=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:0nIpcjjFj57Qa3KW/6WhEeKk+Ms= sha1:qhn01y2tqIkY+8/6lzQopMKjE5A= Xref: csiph.com comp.lang.c:395824 James Kuyper writes: > On 2025-08-05 17:25, Kaz Kylheku wrote: > >> On 2025-08-05, Keith Thompson wrote: >> >>> Breaking existing code that uses "_BitInt" as an identifier is >>> a non-issue. There very probably is no such code. >> >> However, that doesn't mean GCC can carelessly introduce identifiers >> in this namespace. >> >> GCC does not define a complete C implementation; it doesn't provide a >> library. Libraries are provided by other projects: Glibc, Musl, >> ucLibc, ... >> >> Those libraries are C implementors also, and get to name things >> in the reserved namespace. > > GCC cannot be implemented in such a way as to create a fully conforming > implementation of C when used in connection with an arbitrary > implementation of the C standard library. This is just one example of a > more general potential problem: Both gcc and the library must use some > reserved identifiers, and they might have made conflicting choices. [...] I'm not sure this assertion is right exactly. The interface to any implementation of the standard library is through a well-defined set of header files. In principle the rest of a C implementation could examine those header files programmatically and systematically avoid any conflicts. Similarly the run-time libraries of the standard library can be examined to avoid any conflicts there. Certainly it isn't convenient to construct such an implementation, but it does seem to be possible.