Deutsch   English   Français   Italiano  
<usopec$4eob$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: James Kuyper <jameskuyper@alumni.caltech.edu>
Newsgroups: comp.lang.c
Subject: =?UTF-8?B?UmU6IFdvcmQgRm9yIFRvZGF5OiDigJxVZ2xpZmljYXRpb27igJ0=?=
Date: Tue, 12 Mar 2024 01:33:00 -0400
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <usopec$4eob$1@dont-email.me>
References: <uso6or$3t3jn$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 12 Mar 2024 05:33:00 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="1b2f7d6314d5bff909509365f5964211";
	logging-data="146187"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/oZHaDzPWfjliit8qKvBKONQO4vTBCwzM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:tRoRJOePMqwn+M0Ekte7KchxsZM=
In-Reply-To: <uso6or$3t3jn$3@dont-email.me>
Content-Language: en-US
Bytes: 4375

On 3/11/24 20:14, Lawrence D'Oliveiro wrote:
> From /usr/include/«arch»/bits/select.h on my Debian system:
> 
>     #define __FD_ZERO(s) \
>       do {									      \
>         unsigned int __i;							      \
>         fd_set *__arr = (s);						      \
>         for (__i = 0; __i < sizeof (fd_set) / sizeof (__fd_mask); ++__i)	      \
>           __FDS_BITS (__arr)[__i] = 0;					      \
>       } while (0)
> 
> Note how this macro brings the entire expression for “s” into the
> scope containing those temporary “__i” and “__arr” variables. You just
> better hope they won’t clash.
> 
> I think there is a clause in the C spec that says names beginning with
> underscores (“uglified” names, I think they’re called) are reserved
> for library implementors or something. But what happens if one library
> implementation depends on another? What keeps the choices of names
> from clashing in that situation? Just luck, I guess.

They are called "reserved identifiers", a name which more directly
addresses their purpose. They don't just start with underscores - there
are several different sets of identifiers, reserved for different
purposes. See section 7.1.3 for details. They are provided by *an*
implementation. Note the use of the singular. As far as the standard is
concerned, there is only one implementation that is responsible for
translating and executing a given program. What the implementation
implements is not just the C standard library, but also the C language.
Libraries other than the C standard library do have implementations, but
those implementations are not what the C standard is usually talking
about when it uses that word.

The standard defines an implementation as "particular set of software,
running in a particular translation environment under particular control
options, that performs translation of programs for, and supports
execution of functions in, a particular execution environment" (3.12).

Note that the software must be running before it can be called an
implementation. A program that is just sitting on your computer waiting
to be executed cannot qualify. Also, if the software has options,
choosing different options when you start it up can make it a different
implementation of C.

You can have an implementation of C where different parts are
implemented by different implementors - in fact, it's quite common for
the language, the C standard library, and the linker to be implemented
by different organizations. However, the combination of those parts only
qualifies as a conforming implementation of C if those different parts
work together as required by the standard. Avoiding the conflicts you're
talking about is a pre-requisite for doing so.

Most implementors that implement only part of a C implementation make
sure to test whether their part works together with popular
implementations of the other parts, and to document which ones they do
work with. If you cobble together a complete implementation from parts
implemented by different implementors, you'd better check their
documentation to see if at least one of them has tested compatibility
with all of the others. If none of them has done such testing, you
shouldn't count on them working together as a conforming C implementation.