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.

Basically, string-substitution macros are fiddly, fragile, and prone
to mysterious syntax errors in the target language if you’re not
careful. I thought initially that this was down to limitations in the
the C/C++ preprocessor; maybe a more powerful one, like m4, would
help. But it turns that is even more fiddly and fragile, and prone to
mysterious syntax errors if you’re not careful.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> 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.

N1570 7.1.3:

All identifiers that begin with an underscore and either an
uppercase letter or another underscore are always reserved for any
use.

All identifiers that begin with an underscore are always reserved
for use as identifiers with file scope in both the ordinary and tag
name spaces.

I've never heard them call "uglified", though I suppose it's somewhat apt.

If the standard library includes code from two or more different
implementers, all implementers have a very strong interest in avoiding
any clashes. I don't see a real problem here.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Mon, 11 Mar 2024 18:15:06 -0700, Keith Thompson wrote:

> If the standard library includes code from two or more different
> implementers, all implementers have a very strong interest in avoiding
> any clashes. I don't see a real problem here.

.... until the Birthday Paradox comes into play.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Mon, 11 Mar 2024 18:15:06 -0700, Keith Thompson wrote:
>
>> If the standard library includes code from two or more different
>> implementers, all implementers have a very strong interest in avoiding
>> any clashes. I don't see a real problem here.
>
> ... until the Birthday Paradox comes into play.

The Birthday Paradox comes into play for random birthdays over which the
participants have no control, not for library implementers who control
their own namespaces and are strongly motivated to avoid collisions.

Do you have a real-world example of such a collision?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 2024-03-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> From /usr/include/«arch»/bits/select.h on my Debian system:
>
> #define __FD_ZERO(s) \
> do { \
> unsigned int __i; \
> fd_set *__arr = (s); \

This assignment has value; it checks that, loosely speaking,
s is an "assignment compatible" pointer with a fd_set *,
so that there is a diagnostic if the macro is applied to
an object of the wrong type.

> for (__i = 0; __i < sizeof (fd_set) / sizeof (__fd_mask); ++__i) \
> __FDS_BITS (__arr)[__i] = 0; \

Here, I would have done memset(__arr, 0, sizeof *__arr).

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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.

On Tue, 12 Mar 2024 01:33:00 -0400, James Kuyper wrote:

> 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.

Looking at the C99 spec, section 7.1.3:

Also reserved for the implementor are all external identifiers
beginning with an underscore, and all other identifiers beginning
with an underscore followed by a capital letter or an underscore.
This gives a name space for writing the numerous behind-the-scenes
non-external macros and functions a library needs to do its job
properly.

The problem I have with that is the singular form of “library”. In a
typical Linux distro, you could have thousands of libraries installed.
I just did this command on my Debian system:

dpkg-query -l lib*dev | wc -l

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.

On 2024-03-12, Lawrence D'Oliveiro <ldo@nz.invalid> 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.

That doesn't happen. There is only one library that's part of the
language implementation, and those identifiers are reserved for that.

Any third party library that is not part of the implementation cannot
use these identifiers with the absolute certainty that they don't clash
with anything.

Standard C doesn't offer a solution for the problem of party library
writers needing private identifiers in their headers.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Tue, 12 Mar 2024 06:14:58 -0000 (UTC), I wrote:

> I just did this command on my Debian system:
>
> dpkg-query -l lib*dev | wc -l

Let me amend that: the more accurate command (counting only installed
libraries, not all the ones the package system knows about) would be

dpkg-query -l lib\*dev | grep ^i | wc -l

which produces a result of 320 on my system.

On 2024-03-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> The problem I have with that is the singular form of “library”. In a
> typical Linux distro, you could have thousands of libraries installed.
> I just did this command on my Debian system:
>
> dpkg-query -l lib*dev | wc -l
>
> 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.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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.

--
https://www.greenend.org.uk/rjk/

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.)

David Brown:

> 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.)

My hypothetical solution is to have a single function
returning a struct with pointers to all the public functions
of a module.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On 12/03/2024 14:46, Anton Shepelev wrote:
> David Brown:
>
>> 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.)
>
> My hypothetical solution is to have a single function
> returning a struct with pointers to all the public functions
> of a module.
>
What stops that function name clashing with the single function exported
from other people's modules?

bart:
> Anton Shepelev:
> > David Brown:
> >
> > > 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.)
> >
> > My hypothetical solution is to have a single function
> > returning a struct with pointers to all the public
> > functions of a module.
>
> What stops that function name clashing with the single
> function exported from other people's modules?

A much lower probability.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On 12/03/2024 15:09, Anton Shepelev wrote:
> bart:
>> Anton Shepelev:
>>> David Brown:
>>>
>>>> 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.)
>>>
>>> My hypothetical solution is to have a single function
>>> returning a struct with pointers to all the public
>>> functions of a module.
>>
>> What stops that function name clashing with the single
>> function exported from other people's modules?
>
> A much lower probability.
>

I tried my C compiler with a couple of open source projects recently
that both failed for the same mysterious reason.

It turned out that one of them used this line:

#include "string.h"

and the other used:

#include "malloc.h"

Notice they use "..." rather than <...>. These are not the standard
headers, but user-written headers with the same names. (My compiler
looks for them in the wrong order.)

People like reusing the same popular module names so much, they will
even use the names of standard headers! Any exported function name is
likely to be linked to the name of the module.

>>> returning a struct with pointers to all the public
>>> functions of a module.

There may be an additional clash-point with exposing the name of the struct.

On 3/12/24 02:14, Lawrence D'Oliveiro wrote:
....
> The problem I have with that is the singular form of “library”. In a
> typical Linux distro, you could have thousands of libraries installed.
> I just did this command on my Debian system:
>
> dpkg-query -l lib*dev | wc -l
>
> 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.

It was never monolithic, any more than talking about the United States
implies that the United States is a monolithic entity. The standard
allows an implementation to have many separate parts, by failing to
prohibit such a structure - but everything it says about one is about
the implementation as a whole, not the individual parts.

On 2024-03-12, bart <bc@freeuk.com> wrote:
> On 12/03/2024 14:46, Anton Shepelev wrote:
>> David Brown:
>>
>>> 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.)
>>
>> My hypothetical solution is to have a single function
>> returning a struct with pointers to all the public functions
>> of a module.
>>
> What stops that function name clashing with the single function exported
> from other people's modules?

There are multiple possible answers here.

One is that even if such functions have to be uniquely named, that is a
lesser burden than all API functions having to be uniquely named.
The probability of a clash is reduced, and at most one function
has to be renamed if it occurs.

There are ways that this single function can have the same name
in every component.

For instance, under Microsoft COM, COM DLLs provide well-known
functions like DllGetClassObject, DllRegisterServer and
DllUnregisterServer.

These don't clash since they are in different DLLs.

An appliation queries for the COM object using its class ID,
which is a GUID. That must be unique. DllRegisterServer registers
it in the registry.

Variations on this theme can be done in any system that has dynamic
libraries or loadable modules.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2024-03-12, bart <bc@freeuk.com> wrote:
> On 12/03/2024 15:09, Anton Shepelev wrote:
>> bart:
>>> Anton Shepelev:
>>>> David Brown:
>>>>
>>>>> 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.)
>>>>
>>>> My hypothetical solution is to have a single function
>>>> returning a struct with pointers to all the public
>>>> functions of a module.
>>>
>>> What stops that function name clashing with the single
>>> function exported from other people's modules?
>>
>> A much lower probability.
>>
>
> I tried my C compiler with a couple of open source projects recently
> that both failed for the same mysterious reason.
>
> It turned out that one of them used this line:
>
> #include "string.h"
>
> and the other used:
>
> #include "malloc.h"

In the TXR project, I have a "signal.h" header, which must not resolve
to <signal.h>. I also have "time.h" and "termios.h", "glob.h",
"regex.h", "alloca.h".

Choosing header names that are distinct from an implementation's
headers is:

1) unnecessary due the local-first search strategy of #include "..."

2) a fool's errand.

Regarding (2), no name that you choose is guaranteed not to be identical
to something in the implementation! Suppose I panic and rename
my "time.h" to "foo.h". Who is to say that some implementation doesn't
have a <foo.h> header?

There is no such rule that when you name a "whatever.h", you must
ensure there does not exist a <whatever.h>.

> People like reusing the same popular module names so much, they will
> even use the names of standard headers!

Sometimes deliberately so. Why did I call that header "termios.h"
is that the module is relates to is related to the POSIX termios;
the source file is called termios.c and includes <termios.h> as
well as its own "termios.h". This makes things readable; someone
looking at the directory listing can guess that these files
constitute a module which wraps termios.

Any other naming would obscure that to some degree, other than
perhaps longer names that contain "termios" as a substring.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Tue, 12 Mar 2024 11:51:21 -0400, James Kuyper wrote:

> ... everything it says about one is about
> the implementation as a whole, not the individual parts.

You don’t see the problem with trying avoid clashes between those parts?

David Brown wrote:

> 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.)

Many libraries put a prefix on their identifiers as a form of
psuedonamespacing.

--
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
The law prohibits underwater smoking!

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 12 Mar 2024 11:51:21 -0400, James Kuyper wrote:
>> ... everything it says about one is about
>> the implementation as a whole, not the individual parts.
>
> You don’t see the problem with trying avoid clashes between those parts?

I think everyone is aware of the problem. Was that your point?

The standard reserves certain identifiers for use by the implementation.
The implementation includes the standard library described in section 7,
not to all the libraries that happen to be installed on a system; those
libraries, as far as the standard is concerned, are just user code.
Third-party libraries are, for example, not permitted to define
identifiers starting with two underscores, because those same
identifiers might be used by the standard library or by the compiler.
This is typically not enforced, but using such an identifier in code
that's not part of the standard library has undefined behavior. (I've
seen plenty of such identifiers in third-party code; it typically
doesn't cause a problem in practice unless there's an actual collision.)

If your point is that "name collisions are a problem", of course that's
true. Name collisions within the standard library are typically not a
problem. The standard library is typically provided either by a single
implementer or by a few implementers who are very careful to avoid
collisions.

C doesn't provide a namespace facility like C++'s, so implementers of
third-party libraries might use identifier prefixes or other tricks to
avoid collisions.

Again, have you actually seen name collision problems in the real world?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 12/03/2024 18:50, Kaz Kylheku wrote:
> On 2024-03-12, bart <bc@freeuk.com> wrote:

>> I tried my C compiler with a couple of open source projects recently
>> that both failed for the same mysterious reason.
>>
>> It turned out that one of them used this line:
>>
>> #include "string.h"
>>
>> and the other used:
>>
>> #include "malloc.h"
>
> In the TXR project, I have a "signal.h" header, which must not resolve
> to <signal.h>. I also have "time.h" and "termios.h", "glob.h",
> "regex.h", "alloca.h".
>
> Choosing header names that are distinct from an implementation's
> headers is:
>
> 1) unnecessary due the local-first search strategy of #include "..."
>
> 2) a fool's errand.

It's confusing. So "string.h" means the standard header, so it is the
same as <string.h>, unless it happens to find a file called string.h
amongst the project files.

That is undesirable, unless you specifically want to shadow the standard
headers. In the examples I saw, that was not the case.

> Regarding (2), no name that you choose is guaranteed not to be identical
> to something in the implementation! Suppose I panic and rename
> my "time.h" to "foo.h". Who is to say that some implementation doesn't
> have a <foo.h> header?

The C implementation? Surely that will list all the system headers that
it provides; it looks quite easy to avoid a clash!

>
> There is no such rule that when you name a "whatever.h", you must
> ensure there does not exist a <whatever.h>.

You mean that programs should be allowed to do this:

#include <string.h>
#include "string.h"

With the two headers doing totally different things.

I can guess the reasons why such a rule doesn't exist, because so many
programs just carelessly used "..." instead of <...>, and they would all
break if it was imposed.

>> People like reusing the same popular module names so much, they will
>> even use the names of standard headers!
>
> Sometimes deliberately so. Why did I call that header "termios.h"
> is that the module is relates to is related to the POSIX termios;
> the source file is called termios.c and includes <termios.h> as
> well as its own "termios.h". This makes things readable; someone
> looking at the directory listing can guess that these files
> constitute a module which wraps termios.

So, is that /your/ file termios.c, or the one that implements the POSIX
termios code?

If it is your file, does it wrap the standard one, or replace it?
Generally if you want to wrap X, you call the wrapper Y; having both
called X is troublesome. Supposed somebody wanted to wrap your X, and
they wanted theirs called X too.

Suppose you want two different wrappers for X...

> Any other naming would obscure that to some degree, other than
> perhaps longer names that contain "termios" as a substring.

bart <bc@freeuk.com> writes:
> On 12/03/2024 18:50, Kaz Kylheku wrote:
>> On 2024-03-12, bart <bc@freeuk.com> wrote:
>>> I tried my C compiler with a couple of open source projects recently
>>> that both failed for the same mysterious reason.
>>>
>>> It turned out that one of them used this line:
>>>
>>> #include "string.h"
>>>
>>> and the other used:
>>>
>>> #include "malloc.h"

Note that malloc.h is not a standard header.

Apparently this helped you find and fix a bug in your compiler.

>> In the TXR project, I have a "signal.h" header, which must not
>> resolve to <signal.h>. I also have "time.h" and "termios.h",
>> "glob.h", "regex.h", "alloca.h".
>> Choosing header names that are distinct from an implementation's
>> headers is:
>> 1) unnecessary due the local-first search strategy of #include "..."
>> 2) a fool's errand.
>
> It's confusing. So "string.h" means the standard header, so it is the
> same as <string.h>, unless it happens to find a file called string.h
> amongst the project files.

Yes. But it doesn't "happen to" find a file called string.h; that file
is part of the project. You've just explained it correctly, so I'm not
sure what confuses you.

> That is undesirable, unless you specifically want to shadow the
> standard headers. In the examples I saw, that was not the case.

You didn't mention that. If you'd tell us what project you're talking
about, maybe we could discuss it. Perhaps

>> Regarding (2), no name that you choose is guaranteed not to be identical
>> to something in the implementation! Suppose I panic and rename
>> my "time.h" to "foo.h". Who is to say that some implementation doesn't
>> have a <foo.h> header?
>
> The C implementation? Surely that will list all the system headers
> that it provides; it looks quite easy to avoid a clash!
>
>> There is no such rule that when you name a "whatever.h", you must
>> ensure there does not exist a <whatever.h>.
>
> You mean that programs should be allowed to do this:
>
> #include <string.h>
> #include "string.h"
>
> With the two headers doing totally different things.

I'm not going to say that programs *should* be allowed to do that, but
the fact is that they *are* allowed to do that.

Read section 6.10.2 of the standard. It describes the search rules for
the #include directive.

To summarize, #include <foo.h> searches for a header (probably but not
necessarily a file) identified by foo.h. #include "foo.h" searches for
a *file* called foo.h, and if that fails it then searches for a header
identified by <foo.h>. The sequences for both searches are
implementation-defined.

(The standard does mention the possibility that the "foo.h" search is
not supported. Any such implementation would not be able to handle
user-defined header files; perhaps they would have to be installed as
"headers" somehow. In every implementation I know about, the compiler
will *at least* find the foo.h file if it's in the same directory as the
file that includes it. And if an implementation is able to handle
#include "foo.h", it can also handle #include "string.h".)

If you provide a file called "string.h" as part of your project, and set
up the implementation-defined search paths correctly, then
#include "string.h"
refers to the file in your project, and
#include <string.h>
refers to the standard header.

Having <string.h> and "string.h" do "totally different things" would
perhaps be unwise, but nothing in the standard forbids it. (I wonder
if you think it could or should.)

> I can guess the reasons why such a rule doesn't exist, because so many
> programs just carelessly used "..." instead of <...>, and they would
> all break if it was imposed.

No they wouldn't -- or rather, no they don't. A program that carelessly
uses #include "string.h" to refer to the standard header will work just
fine as long as the project doesn't have a file by that name. The
initial search will fail, and then it will find the standard header.
Certainly #include <string.h> is better style. And a program that
deliberately uses #include "string.h" to refer to its own file by that
name, it will work correctly as long as the search path is set up
correctly.

I'm personally not entirely comfortable with mirroring standard header
names, like using #include "string.h" to use a header file that wraps
the standard header <string.h>. My first thought on seeing that would
be to think that the author should have used <> rather than "". There's
also some risk that if you don't set up the search path correctly,
#include "string.h" could refer to the standard header. But I can see
how it would be useful, and nothing in the language forbids it. If a
project uses such a scheme consistently, I have no problem with it,
beyond a brief moment of "Oh, that's what you're doing".

I might prefer #include "string_wrapper.h".

[snip]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Tue, 12 Mar 2024 08:03:50 +0000, Richard Kettlewell wrote:

> 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.

My specific complaint was about temporary names being used internal to
library macros. It’s a problem that is essentially impossible to solve
with string-based macro processors.