Re: Word For Today: “Uglification”

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