Re: Word For Today: “Uglification”

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