Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
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: <usp9m5$7it7$1@dont-email.me>
References: <uso6or$3t3jn$3@dont-email.me> <usopec$4eob$1@dont-email.me>
 <usort1$4t2r$1@dont-email.me> <20240312003531.349@kylheku.com>
 <wwvwmq7x4ex.fsf@LkoBDZeT.terraraq.uk>
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: <wwvwmq7x4ex.fsf@LkoBDZeT.terraraq.uk>
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 <ldo@nz.invalid> 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.)