Re: Word For Today: “Uglification”

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.