Re: Word For Today: “Uglification”

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.