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

Here's the macro definition you cited upthread:
"""
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)
"""

Can you explain how that would cause a problem?

Note the following that precedes the macro definition in
/usr/include/x86_64-linux-gnu/bits/select.h on my Ubuntu system:

"""
#ifndef _SYS_SELECT_H
# error "Never use <bits/select.h> directly; include <sys/select.h> instead."
#endif
"""

so it's not going to be invoked from user-written code.

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

Firstly, C preprocessing is not exactly "string based" but token based.

A string or token based macro preprocessor could provide a way for
macros to obtain and use generated symbols (gensyms): identifiers
that are valid in the host language for variables and other uses,
but are uniquely generated within the translation unit.

Needless to say, the standard C preprocessing doesn't provide such a
thing, which is a problem.

But this issue independent of weaknesses caused by macro processing
being token or character based. A structural macro preprocessor that
doesn't provide gensyms or any equivalent form of hygiene would have the
same problem.

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

It's not confusing at all. In projects under my control, you would
never see #include "string.h" where the intent is to include <string.h>.
It is a lousy practice.

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

You cannot shadow the standard headers when they are correctly included
using #include <...>, unless you resort to compiler specific tricks,
like reconfiguring the <...> search to look in a specified directory.
>
>
>> 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!

But there is no clash to avoid. A local header file that accidentally
has the same name as something in your /usr/include or whatever
is no problem at all, if you refer to it using #include "...".

But if there were a clash to be avoided, it would be tricky.

Not all headers are documented, so you would have to actually go looking
into the header file installation.

The information there is no reliable for portability, because all you
learn is what files are present in that installation.

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

No I mean, that programs /are/.

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

Those programs don't break, because if "string.h" doesn't exist,
then it is re-tried as if it were <string.h> (effectively).

(I don't think it's the best design; it would be better if "..."
and <...> looked in separate places with no fallback from one
to the other, such that #include "stdio.h" programs not
referencing a local file would break.)

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

Since my project isn't an operating system, or library for one,
but a dynamic language runtime, it has to be the former.

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

On 3/12/24 17:31, Lawrence D'Oliveiro wrote:
> 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?

Yes, I do, and so do implementors. Avoiding those clashes is their
responsibility. They are supposed to test their partial implementations
with implementations of other parts of C, and document which
combinations they claim qualify as conforming implementations of C. I'm
not saying this is required by the C standard, but only by their general
responsibility to produce a usable product.

The C standard only governs things which claim to be conforming
implementations of C. It cannot constrain things for which no such claim
has been made. If you want to rely upon guarantees provided by the C
standard, only use things which claim to meet its requirements.

Therefore, your responsibility is to read the documentation of any
partial implementations you put together, and only put together partial
implementations for which such a claim has been made.

Or, if you choose to mix and match partial implementations willy-nilly,
own your choice and don't complain about the results.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> 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.
>
> Here's the macro definition you cited upthread:
> """
> 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)
> """
>
> Can you explain how that would cause a problem?

The implementation can use prefixed names as shown, so that example
won’t cause any trouble as long as the implementors coordinate amongst
themselves (which is a reasonable assumption).

Any library from outside the implementation doesn’t have that privilege
and just has to hope that the internal names it chooses don’t collide
with anything else that’s visible when its header(s) are included.

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

On 12/03/2024 23:00, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:

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

That's not really relevant. Suffice that they are amateur projects and
clearly they were using using string.h etc for their own purposes
without thinking.

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

Not in N1570 it doesn't. It seems mainly concerned with the syntax.

I understand that the algorithm for finding include files was
implementation-defined, and typically depended on these inputs:

* Whether the filename used "..." or <...>
* Whether the file-name specified was absolute or relative
* The path of the source file in which the #include occurs
* Possibly, the complete stack of paths for the current sequence set of
nested #includes
* Possibly, on the CWD
* On where the compiler keeps its standard headers (which in turn may
depend on OS)
* On the set of -I directives given to the compiler (this is
something outside the remit of the standard, AIUI)

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

This is something new I saw today: suppose I have hello.c in a directory
(hello.c uses '#include <stdio.h>').

If I create an empty file called 'stdio.h', then 4 compilers I tried all
picked up that file instead of their official stdio.h. That looks a
dangerous practice to me.

It also seems, for a <...> file, to ignore the official repository and
look first within the user's project. So what exactly is the difference
between <...> and "..."? Is it just an extra set of backup paths to look
if it can't find anything within the user's files?

(The 5th compiler I tried ignored it and worked as normal; that was
mine. I can make it fail using my '-ext' option to look elsewhere than
the official headers location. I don't make a distinction between <...>
and "...".)

On Wed, 13 Mar 2024 11:45:31 +0000
bart <bc@freeuk.com> wrote:
>
>
> This is something new I saw today: suppose I have hello.c in a
> directory (hello.c uses '#include <stdio.h>').
>
> If I create an empty file called 'stdio.h', then 4 compilers I tried
> all picked up that file instead of their official stdio.h. That looks
> a dangerous practice to me.
>
> It also seems, for a <...> file, to ignore the official repository
> and look first within the user's project. So what exactly is the
> difference between <...> and "..."? Is it just an extra set of backup
> paths to look if it can't find anything within the user's files?
>
> (The 5th compiler I tried ignored it and worked as normal; that was
> mine. I can make it fail using my '-ext' option to look elsewhere
> than the official headers location. I don't make a distinction
> between <...> and "...".)
>
>

I just tried three compilers and [in absence of -I options] all 3 work
as expected, i.e. ignored stdio.h in current directory.
None of the three was of the variety that you appear to prefer.
Mine's are mundane stuff.

However all three took local file when I had given them an option -I.
Not sure what to make of this. Whatever happens with
non-default options is probably in "implementation-defined"
domain as far as the C Standard is concerned, but I still
expected that such common option as -I would not affect standard
headers.

Richard Kettlewell <invalid@invalid.invalid> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> 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.
>>
>> Here's the macro definition you cited upthread:
>> """
>> 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)
>> """
>>
>> Can you explain how that would cause a problem?
>
> The implementation can use prefixed names as shown, so that example
> won’t cause any trouble as long as the implementors coordinate amongst
> themselves (which is a reasonable assumption).
>
> Any library from outside the implementation doesn’t have that privilege
> and just has to hope that the internal names it chooses don’t collide
> with anything else that’s visible when its header(s) are included.

Any library from outside the implementation cannot use reserved
identifiers without invoking undefined behavior, any more than ordinary
user code can do so. In practice, third-party code can (probably) get
away with using reserved identifiers as long as there isn't an actual
collision. (A compiler could enforce a general restriction on using
reserved identifiers, but I don't know of any that do so.)

--
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 */

Michael S <already5chosen@yahoo.com> writes:
[...]
> I just tried three compilers and [in absence of -I options] all 3 work
> as expected, i.e. ignored stdio.h in current directory.
> None of the three was of the variety that you appear to prefer.
> Mine's are mundane stuff.
>
> However all three took local file when I had given them an option -I.
> Not sure what to make of this. Whatever happens with
> non-default options is probably in "implementation-defined"
> domain as far as the C Standard is concerned, but I still
> expected that such common option as -I would not affect standard
> headers.

According to the GNU cpp manual, the "-I" option prepends directories to
the search path used for <> headers, and the "-iquote" option prepends
directories to the search path used for "" headers.

I find that a bit surprising. I had never heard of the "-iquote"
option.

--
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 13/03/2024 13:12, Michael S wrote:
> On Wed, 13 Mar 2024 11:45:31 +0000
> bart <bc@freeuk.com> wrote:
>>
>>
>> This is something new I saw today: suppose I have hello.c in a
>> directory (hello.c uses '#include <stdio.h>').
>>
>> If I create an empty file called 'stdio.h', then 4 compilers I tried
>> all picked up that file instead of their official stdio.h. That looks
>> a dangerous practice to me.

I'd agree it seems a poor choice of defaults.

As you know, the details of the searching mechanism is
implementation-dependent. But it is common practice to have two lists
of paths - one for "system headers" (for #include <...>), and one for
"user headers" (for #include "..."). (The C standards refer to the
former as "headers" and the later just as "source files for inclusion",
but I think the system/user header file distinction is more user-friendly!)

The system header path typically includes first the directory or
directories containing the standard library headers, but can also
include OS-specific headers, POSIX headers, and any other headers that
are considered part of the C implementation. (For cross-compilers,
these will directories with for the target's C library headers rather
than the host files.)

The user header path will typically be just the directory of the source
file, but may also include the current directory.

Command-line flags generally allow you to replace or extend these.

A failed search for a "..." file should move on to the system header
path, but not vice-versa.

So, which compilers (and relevant flags) had the system header search
start in the current directory? It is not disallowed, AFAIUI, but it
seems a bad idea to me.

>>
>> It also seems, for a <...> file, to ignore the official repository
>> and look first within the user's project. So what exactly is the
>> difference between <...> and "..."? Is it just an extra set of backup
>> paths to look if it can't find anything within the user's files?
>>
>> (The 5th compiler I tried ignored it and worked as normal; that was
>> mine. I can make it fail using my '-ext' option to look elsewhere
>> than the official headers location. I don't make a distinction
>> between <...> and "...".)
>>
>>
>
> I just tried three compilers and [in absence of -I options] all 3 work
> as expected, i.e. ignored stdio.h in current directory.
> None of the three was of the variety that you appear to prefer.
> Mine's are mundane stuff.
>
> However all three took local file when I had given them an option -I.
> Not sure what to make of this.

What exactly was the "-I" option you gave (and which compiler)? If you
wrote "-I.", including the dot, then gcc will act the way you describe -
that's what the flag does. If you put other directories in the -I list,
it does not look in the current directory.

<https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html>

> Whatever happens with
> non-default options is probably in "implementation-defined"
> domain as far as the C Standard is concerned, but I still
> expected that such common option as -I would not affect standard
> headers.
>

On 2024-03-13, Michael S <already5chosen@yahoo.com> wrote:
> I just tried three compilers and [in absence of -I options] all 3 work
> as expected, i.e. ignored stdio.h in current directory.
> None of the three was of the variety that you appear to prefer.
> Mine's are mundane stuff.
>
> However all three took local file when I had given them an option -I.

Yes; the traditional -I option is idiotic for the majority of the use
cases for which it has actually been used. This is why GCC introduced
-iquote; that's what you want to be using within a project for
redirecting your local #include "...".

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

bart <bc@freeuk.com> writes:
> On 12/03/2024 23:00, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> 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
>
> That's not really relevant. Suffice that they are amateur projects and
> clearly they were using using string.h etc for their own purposes
> without thinking.

As far as I can tell from what you've written, they may have been using
"string.h" correctly, as a local file that's part of the project.

>> Read section 6.10.2 of the standard. It describes the search rules for
>> the #include directive.
>
> Not in N1570 it doesn't. It seems mainly concerned with the syntax.

"""
A preprocessing directive of the form
# include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header
identified uniquely by the specified sequence between the < and >
delimiters,
"""
and so on. That's what I meant when I said it describes the search
rules. It doesn't completely define them.

> I understand that the algorithm for finding include files was
> implementation-defined, and typically depended on these inputs:
>
> * Whether the filename used "..." or <...>
> * Whether the file-name specified was absolute or relative
> * The path of the source file in which the #include occurs
> * Possibly, the complete stack of paths for the current sequence set of
> nested #includes
> * Possibly, on the CWD
> * On where the compiler keeps its standard headers (which in turn may
> depend on OS)
> * On the set of -I directives given to the compiler (this is
> something outside the remit of the standard, AIUI)

Yes -- but you left out a major part of it, that if a search for a ""
header fails, it continues by treating it as if it were a <> header.
Thus #include "stdio.h" will use a header file by that name if it
exists, and is equivalent to #include <stdio.h> otherwise.

>> 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.
>
> This is something new I saw today: suppose I have hello.c in a
> directory (hello.c uses '#include <stdio.h>').
>
> If I create an empty file called 'stdio.h', then 4 compilers I tried
> all picked up that file instead of their official stdio.h. That looks
> a dangerous practice to me.

If they're behaving as you're describing, then they're not conforming.
I've tried gcc, clang, and tcc, and all pick up the correct <stdio.h>
header even if there's a "stdio.h" file in the current directory.

It's possible in principle that a compiler could include the current
directory in the <> search path, but that would be surprising, and none
of the compilers I've tried do so.

What are these 4 compilers? Are you sure you used <stdio.h> and not
"stdio.h"? Did you use any additional command line options? Might you
have set some environment variable like $C_INCLUDE PATH that affects the
behavior?

> It also seems, for a <...> file, to ignore the official repository and
> look first within the user's project. So what exactly is the
> difference between <...> and "..."? Is it just an extra set of backup
> paths to look if it can't find anything within the user's files?

The difference is as I've described above.

> (The 5th compiler I tried ignored it and worked as normal; that was
> mine. I can make it fail using my '-ext' option to look elsewhere than
> the official headers location. I don't make a distinction between
> <...> and "...".)

Perhaps I'm missing something. If your compiler doesn't distinguish
between <> and "", then #include "stdio.h" should be equivalent to
#include <stdio.h>. You say it ignores a stdio.h file in the current
directory. Then how can a source file include *any* header file in the
current directory?

#include <stdio.h> // This includes the system header.
#include "stdio.h" // You say this ignores any local file and
// includes the system header.
#include "foo.h" // Does this not include a local file named "foo.h"?

--
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 13/03/2024 16:03, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:

>> I understand that the algorithm for finding include files was
>> implementation-defined, and typically depended on these inputs:
>>
>> * Whether the filename used "..." or <...>
>> * Whether the file-name specified was absolute or relative
>> * The path of the source file in which the #include occurs
>> * Possibly, the complete stack of paths for the current sequence set of
>> nested #includes
>> * Possibly, on the CWD
>> * On where the compiler keeps its standard headers (which in turn may
>> depend on OS)
>> * On the set of -I directives given to the compiler (this is
>> something outside the remit of the standard, AIUI)
>
> Yes -- but you left out a major part of it, that if a search for a ""
> header fails, it continues by treating it as if it were a <> header.

I didn't attempt to describe the algorithm, only to list the various
variables.

>> If I create an empty file called 'stdio.h', then 4 compilers I tried
>> all picked up that file instead of their official stdio.h. That looks
>> a dangerous practice to me.
>
> If they're behaving as you're describing, then they're not conforming.
> I've tried gcc, clang, and tcc, and all pick up the correct <stdio.h>
> header even if there's a "stdio.h" file in the current directory.
>
> It's possible in principle that a compiler could include the current
> directory in the <> search path, but that would be surprising, and none
> of the compilers I've tried do so.
>
> What are these 4 compilers? Are you sure you used <stdio.h> and not
> "stdio.h"? Did you use any additional command line options? Might you
> have set some environment variable like $C_INCLUDE PATH that affects the
> behavior?

My observations were erroneous. It turned out I'd been messing about
with hello.c (when investigating these matters a few days ago) so that
it was using "stdio.h" rather than <stdio.h>.

So 3 of the 4 compilers (gcc, tcc, dmc) behave as Michael S described,
and will only look at the current directory, or wherever the source file
is, if -I. or -Ipath is used.

The 4th compiler is lccwin32 which still looks first inside the same
directory as the source file (not CWD). I now remember this from many
years ago when it caused some trouble because of a rogue stdio.h lying
about.

>> (The 5th compiler I tried ignored it and worked as normal; that was
>> mine. I can make it fail using my '-ext' option to look elsewhere than
>> the official headers location. I don't make a distinction between
>> <...> and "...".)
>
> Perhaps I'm missing something. If your compiler doesn't distinguish
> between <> and "", then #include "stdio.h" should be equivalent to
> #include <stdio.h>. You say it ignores a stdio.h file in the current
> directory. Then how can a source file include *any* header file in the
> current directory?

> #include <stdio.h> // This includes the system header.
> #include "stdio.h" // You say this ignores any local file and
> // includes the system header.
> #include "foo.h" // Does this not include a local file named "foo.h"?
>

<...> are not special, but it knows which are the standard headers
because there is a list of them in the compiler.

So if an include file is one of those, then it will look inside the
compiler because that's where the headers files are embedded. This
allows the compiler to be self-contained.

To override that, the `-ext` option is used, then an include file is
searched for like any ordinary file.

(Which is first in the directory containing the current source file,
then CWD, then any extra include paths specified.

I think it's more elaborate than that, because if this is a nested
include, there will be a stack of 'current source files' whose paths are
searched in top-down order.

Probably CWD should not be part of this, but the process is already so
convoluted that I can't be bothered to change it.

In my non-C language, any auxiliary files are looked in exactly ONE
location. Then you don't have the problem of C where if an include file
is missing or renamed, it might instead find an identically-named but
WRONG file in another location.)

On Tue, 12 Mar 2024 16:00:05 -0700, Keith Thompson wrote:
> (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.

The POSIX-standard compiler commands (c89, c99) require #include
searches to work this way so it's not surprising that today, most
compilers work like this.

However some traditional compilers (for example, VAX C) search relative
to the current working directory of the running compiler for #include
"foo.h", rather than the directory containing the source file.

Standard C does not forbid such behaviour and standard C predates the
first version of POSIX.2 by a few years so there are probably some
standard C compilers that work like VAX C.

On 13/03/2024 16:15, Keith Thompson wrote:
> Michael S <already5chosen@yahoo.com> writes:
> [...]
>> I just tried three compilers and [in absence of -I options] all 3 work
>> as expected, i.e. ignored stdio.h in current directory.
>> None of the three was of the variety that you appear to prefer.
>> Mine's are mundane stuff.
>>
>> However all three took local file when I had given them an option -I.
>> Not sure what to make of this. Whatever happens with
>> non-default options is probably in "implementation-defined"
>> domain as far as the C Standard is concerned, but I still
>> expected that such common option as -I would not affect standard
>> headers.
>
> According to the GNU cpp manual, the "-I" option prepends directories to
> the search path used for <> headers, and the "-iquote" option prepends
> directories to the search path used for "" headers.
>
> I find that a bit surprising.

You are not quite correct - and I find /that/ a bit surprising!

The -I option applies equally to <...> and "..." headers.

> I had never heard of the "-iquote"
> option.
>

The complete description is here:
<https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html>. (It is the
same in the cpp manual, but it is better to look at the compiler manual
for this kind of thing - after all, the gcc driver program can pass
different options to the cpp subprogram.)

To save people looking it up:

-I dir
-iquote dir
-isystem dir
-idirafter dir

Add the directory dir to the list of directories to be searched for
header files during preprocessing. If dir begins with ‘=’ or $SYSROOT,
then the ‘=’ or $SYSROOT is replaced by the sysroot prefix; see
--sysroot and -isysroot.

Directories specified with -iquote apply only to the quote form of
the directive, #include "file". Directories specified with -I, -isystem,
or -idirafter apply to lookup for both the #include "file" and #include
<file> directives.

You can specify any number or combination of these options on the
command line to search for header files in several directories. The
lookup order is as follows:

For the quote form of the include directive, the directory of
the current file is searched first.
For the quote form of the include directive, the directories
specified by -iquote options are searched in left-to-right order, as
they appear on the command line.
Directories specified with -I options are scanned in
left-to-right order.
Directories specified with -isystem options are scanned in
left-to-right order.
Standard system directories are scanned.
Directories specified with -idirafter options are scanned in
left-to-right order.

You can use -I to override a system header file, substituting your
own version, since these directories are searched before the standard
system header file directories. However, you should not use this option
to add directories that contain vendor-supplied system header files; use
-isystem for that.

The -isystem and -idirafter options also mark the directory as a
system directory, so that it gets the same special treatment that is
applied to the standard system directories.

If a standard system include directory, or a directory specified
with -isystem, is also specified with -I, the -I option is ignored. The
directory is still searched but as a system directory at its normal
position in the system include chain. This is to ensure that GCC’s
procedure to fix buggy system headers and the ordering for the
#include_next directive are not inadvertently changed. If you really
need to change the search order for system directories, use the
-nostdinc and/or -isystem options.

David Brown <david.brown@hesbynett.no> writes:
> On 13/03/2024 16:15, Keith Thompson wrote:
>> Michael S <already5chosen@yahoo.com> writes:
>> [...]
>>> I just tried three compilers and [in absence of -I options] all 3 work
>>> as expected, i.e. ignored stdio.h in current directory.
>>> None of the three was of the variety that you appear to prefer.
>>> Mine's are mundane stuff.
>>>
>>> However all three took local file when I had given them an option -I.
>>> Not sure what to make of this. Whatever happens with
>>> non-default options is probably in "implementation-defined"
>>> domain as far as the C Standard is concerned, but I still
>>> expected that such common option as -I would not affect standard
>>> headers.
>> According to the GNU cpp manual, the "-I" option prepends
>> directories to
>> the search path used for <> headers, and the "-iquote" option prepends
>> directories to the search path used for "" headers.
>> I find that a bit surprising.
>
> You are not quite correct - and I find /that/ a bit surprising!
>
> The -I option applies equally to <...> and "..." headers.

I believe that's consistent with what I wrote, though I probably wasn't
clear enough. To expand on it:

There are two lists of locations (typically directories). Let's call
them the <>-list (described in N1570 6.10.2p2) and the ""-list
(described in N1570 6.10.2p3).

#include <foo.h> searches the <>-list.

#include "foo.h" searches the ""-list; if that fails, it then searches
the <>-list as if for #include <foo.h>.

The -I option prepends directories to the <>-list, which means it
affects both #include <foo.h> and #include "foo.h". But for
#include "foo.h", a foo.h file in the same directory as the including
file will always be found first if it exists.

[...]

> The complete description is here:
> <https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html>.
[...]
[slightly reformatting quoted text]
> 1. For the quote form of the include directive, the directory of
> the current file is searched first.
>
> 2. For the quote form of the include directive, the directories
> specified by -iquote options are searched in left-to-right
> order, as they appear on the command line.
>
> 3. Directories specified with -I options are scanned in
> left-to-right order.
>
> 4. Directories specified with -isystem options are scanned in
> left-to-right order.
>
> 5. Standard system directories are scanned.
>
> 6. Directories specified with -idirafter options are scanned in
> left-to-right order.

What I called the ""-list is described in steps 1-2.
What I called the <>-list is described in steps 3-6.

[...]

--
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 13/03/2024 19:56, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 13/03/2024 16:15, Keith Thompson wrote:
>>> Michael S <already5chosen@yahoo.com> writes:
>>> [...]
>>>> I just tried three compilers and [in absence of -I options] all 3 work
>>>> as expected, i.e. ignored stdio.h in current directory.
>>>> None of the three was of the variety that you appear to prefer.
>>>> Mine's are mundane stuff.
>>>>
>>>> However all three took local file when I had given them an option -I.
>>>> Not sure what to make of this. Whatever happens with
>>>> non-default options is probably in "implementation-defined"
>>>> domain as far as the C Standard is concerned, but I still
>>>> expected that such common option as -I would not affect standard
>>>> headers.
>>> According to the GNU cpp manual, the "-I" option prepends
>>> directories to
>>> the search path used for <> headers, and the "-iquote" option prepends
>>> directories to the search path used for "" headers.
>>> I find that a bit surprising.
>>
>> You are not quite correct - and I find /that/ a bit surprising!
>>
>> The -I option applies equally to <...> and "..." headers.
>
> I believe that's consistent with what I wrote, though I probably wasn't
> clear enough.

Yes, after reading your expanded explanation, I agree with you here
(both parts). Thanks for that clarification.

> To expand on it:
>
> There are two lists of locations (typically directories). Let's call
> them the <>-list (described in N1570 6.10.2p2) and the ""-list
> (described in N1570 6.10.2p3).
>
> #include <foo.h> searches the <>-list.
>
> #include "foo.h" searches the ""-list; if that fails, it then searches
> the <>-list as if for #include <foo.h>.
>
> The -I option prepends directories to the <>-list, which means it
> affects both #include <foo.h> and #include "foo.h". But for
> #include "foo.h", a foo.h file in the same directory as the including
> file will always be found first if it exists.
>
> [...]
>
>> The complete description is here:
>> <https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html>.
> [...]
> [slightly reformatting quoted text]
>> 1. For the quote form of the include directive, the directory of
>> the current file is searched first.
>>
>> 2. For the quote form of the include directive, the directories
>> specified by -iquote options are searched in left-to-right
>> order, as they appear on the command line.
>>
>> 3. Directories specified with -I options are scanned in
>> left-to-right order.
>>
>> 4. Directories specified with -isystem options are scanned in
>> left-to-right order.
>>
>> 5. Standard system directories are scanned.
>>
>> 6. Directories specified with -idirafter options are scanned in
>> left-to-right order.
>
> What I called the ""-list is described in steps 1-2.
> What I called the <>-list is described in steps 3-6.
>
> [...]
>

On Wed, 13 Mar 2024 08:06:28 -0700, Keith Thompson wrote:

> Any library from outside the implementation ...

So you are now distinguishing between libraries from “outside the
implementation” from those that are within it? And saying that those from
“outside” have no right to use mechanisms (such as they are) to minimize
name conflicts with regular user code?

On Wed, 13 Mar 2024 03:36:11 -0400, James Kuyper wrote:

> Yes, I do, and so do implementors. Avoiding those clashes is their
> responsibility.

Implementors of the C standard? What about providers of other libraries?

On 2024-03-13, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Wed, 13 Mar 2024 03:36:11 -0400, James Kuyper wrote:
>
>> Yes, I do, and so do implementors. Avoiding those clashes is their
>> responsibility.
>
> Implementors of the C standard? What about providers of other libraries?

One possible point of view is that the integrators who put together a
GNU/Linux distro effectively take on the role of C implementors.

If a clash takes place among any libraries in Debian or Alpine or GNU
Guix or what have you, you can regard that as a bug in the distro. The
distro can fix it however they see fit: apply a local patch to one or
more libraries, and get possibly get that upstreamed, or not.

(It makes sense to get that upstreamed, because other distros are all
building most of the same libraries; a clash between libraries can
affect any distro the same way as any other.)

In any case, the C standard doesn't distinguish any party other than
implementor and user. Libraries that are not in the implementation are
in the program being presented for translation and linkage, and
clashes in the program are the program's problem.

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

On 2024-03-13, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Wed, 13 Mar 2024 08:06:28 -0700, Keith Thompson wrote:
>
>> Any library from outside the implementation ...
>
> So you are now distinguishing between libraries from “outside the
> implementation” from those that are within it? And saying that those from
> “outside” have no right to use mechanisms (such as they are) to minimize
> name conflicts with regular user code?

Libraries that are not part of the implementation are part of the
C program being presented to the C implementation for translation and
linkage.

They are subject to the requirements placed on a program.

If a program uses identifiers that, for instance, start with double
underscores, then its behavior is undefined, and that goes for those
parts of the program which are libraries.

From the C point of view, external libraries are just translation units
that have been translated and retained in that form, accompanied by
header files.

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

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Wed, 13 Mar 2024 08:06:28 -0700, Keith Thompson wrote:
>> Any library from outside the implementation ...
>
> So you are now distinguishing between libraries from “outside the
> implementation” from those that are within it?

The standard makes that distinction.

> And saying that those from
> “outside” have no right to use mechanisms (such as they are) to minimize
> name conflicts with regular user code?

I didn't say "no right". I said that third-party library code can't
safely define identifers that are reserved to the implementation. Do
you disagree?

Please read section 7.1.3 and tell me what *you* think the rules are.

The fact that certain identifers are reserved for use by the
implementation implies that they cannot safely be used by code that is
not part of the implementation. The standard does not distinguish
between third-party library code and ordinary user code.

As I've said before, third-party library code can probably get away with
using implementation-reserved identifiers if there don't happen to be
any actual collisions. But if my libfoo.h header defines
__SOME_IDENTIFIER, and then a future version of some implementation's
<stdio.h> defines __SOME_IDENTIFIER for its own purposes, then as the
author of libfoo.h *I'm* responsible for resolving the conflict, because
I've written code that doesn't work with a fulli conforming C
implementation.. (If I can resolve the conflict by persuading the
authors of the <stdio.h> to use a different identifier, that's fine.)

Reserved identifiers are a mechanism for avoiding name conficts between
the implementation and other code. C doesn't have great mechanisms for
avoiding name conflicts between third-party libraries. It's not ideal,
and nobody said it is.

--
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 */

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 13 Mar 2024 08:06:28 -0700, Keith Thompson wrote:
>
>> Any library from outside the implementation ...
>
>So you are now distinguishing between libraries from “outside the
>implementation” from those that are within it? And saying that those from
>“outside” have no right to use mechanisms (such as they are) to minimize
>name conflicts with regular user code?

The implementation does not include third-party libraries.

Third party libraries are allowed to use any mechanism they
like to minimize name conflicts other than prefixing with
two underscores.

On Wed, 13 Mar 2024 22:33:02 GMT, Scott Lurndal wrote:

> Third party libraries are allowed to use any mechanism they like to
> minimize name conflicts other than prefixing with two underscores.

But there is no other such mechanism available.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Wed, 13 Mar 2024 22:33:02 GMT, Scott Lurndal wrote:
>> Third party libraries are allowed to use any mechanism they like to
>> minimize name conflicts other than prefixing with two underscores.
>
> But there is no other such mechanism available.

Are you aware that working third party libraries exist, and name
collisions are fairly rare? How do you think that's possible?

There are no 100% reliable mechanisms. There are mechanisms that work
well enough in practice, including using library-specific prefixes.

--
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 */