Path: ...!feeds.phibee-telecom.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Word For Today: =?utf-8?Q?=E2=80=9CUglification=E2=80=9D?=
Date: Wed, 13 Mar 2024 09:03:43 -0700
Organization: None to speak of
Lines: 102
Message-ID: <877ci66rvk.fsf@nosuchdomain.example.com>
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> <usp9m5$7it7$1@dont-email.me>
	<20240312174600.5b88613545da9f667e06a4c6@g{oogle}mail.com>
	<uspqa4$bfao$1@dont-email.me>
	<20240312180904.ac3a5856df424c396689db3e@g{oogle}mail.com>
	<uspt5n$c2bg$1@dont-email.me> <20240312114213.182@kylheku.com>
	<usql0p$hk2k$1@dont-email.me>
	<878r2n839m.fsf@nosuchdomain.example.com>
	<uss3kr$ud17$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: dont-email.me; posting-host="3a33dee2b2d0e1e9aaa54021fdfdfa61";
	logging-data="1091087"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/pXqASH7OBiBt4O87Pzdat"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:b1ZUPV6ROPO73CZliVkQtAv5uNg=
	sha1:bJ6/RuzKGUiFsXzJ0THm+enAFv0=
Bytes: 6093

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