Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: David Brown Newsgroups: comp.lang.c Subject: =?UTF-8?B?UmU6IFdvcmQgRm9yIFRvZGF5OiDigJxVZ2xpZmljYXRpb27igJ0=?= Date: Tue, 12 Mar 2024 11:10:13 +0100 Organization: A noiseless patient Spider Lines: 38 Message-ID: References: <20240312003531.349@kylheku.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Tue, 12 Mar 2024 10:10:13 -0000 (UTC) Injection-Info: dont-email.me; posting-host="28b784db58e8619079c79416bf7fd792"; logging-data="248743"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18ZVdrRRt6YsFpksRqZ+TnNcWQpweAV9dw=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Cancel-Lock: sha1:fQ8/ZePCFLSJSR267g5ebadLK/4= In-Reply-To: Content-Language: en-GB Bytes: 3198 On 12/03/2024 09:03, Richard Kettlewell wrote: > Kaz Kylheku <433-929-6894@kylheku.com> writes: >> On 2024-03-12, Lawrence D'Oliveiro wrote: >>> and the answer came back “1037”. The idea that a C-language >>> implementation and run-time environment is any sense monolithic seems >>> hopelessly out of touch. >> >> There is no such out-of-touch idea. In (say) a Glibc-based system, only >> the GCC, Glibc and kernel headers are part of the implementation (which >> comprises C, POSIX plus GNU and Linux extensions), and only the GCC and >> Glibc library components and their external names. >> >> Other libraries are third parties; the __ and _[A-Z] namespace >> simply doesn't belong to them. >> >> C doesn't provide any special tools for the application developer and >> third party code to avoid clashes among themselves. > > That’s true, but AFAICT it’s exactly what Lawrence is complaining about: > there’s nothing in the language spec to help those thousand other > libraries avoid name clashes. > No, it is /not/ what Lawrence is complaining about. He is complaining about clashes within the reserved namespace, because he didn't understand the difference between the library and headers that make up a C implementation, and other libraries that he happens to have on the system. It's an understandable confusion, since it is an overload of the term "library". But hopefully he understands that now. The limited support for avoiding name clashes in C (user-level C, outside of the implementation internals) is certainly something that he (or others) /could/ complain about. It is a well-known issue, and it's a shame that the C standards committee have never dealt with it. I don't see why the language could not adopt a simple "namespace" solution that would hugely simplify avoiding identifier clashes. (It wouldn't help for macros, but we have inline functions to handle many cases.)