Path: ...!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: Tue, 12 Mar 2024 16:00:05 -0700
Organization: None to speak of
Lines: 120
Message-ID: <878r2n839m.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>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: dont-email.me; posting-host="3a33dee2b2d0e1e9aaa54021fdfdfa61";
	logging-data="590682"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/nH06j5hPGmWKFfLOzmelP"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:8r2Qy/IF0xqslMXuFJD99bv0bSY=
	sha1:rXfXNeZ86J4B0TUO9ZZUWEFTcW8=
Bytes: 6462

bart <bc@freeuk.com> writes:
> 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"

Note that malloc.h is not a standard header.

Apparently this helped you find and fix a bug in your compiler.

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

Yes.  But it doesn't "happen to" find a file called string.h; that file
is part of the project.  You've just explained it correctly, so I'm not
sure what confuses you.

> 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 

>> 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'm not going to say that programs *should* be allowed to do that, but
the fact is that they *are* allowed to do that.

Read section 6.10.2 of the standard.  It describes the search rules for
the #include directive.

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.

(The standard does mention the possibility that the "foo.h" search is
not supported.  Any such implementation would not be able to handle
user-defined header files; perhaps they would have to be installed as
"headers" somehow.  In every implementation I know about, the compiler
will *at least* find the foo.h file if it's in the same directory as the
file that includes it.  And if an implementation is able to handle
#include "foo.h", it can also handle #include "string.h".)

If you provide a file called "string.h" as part of your project, and set
up the implementation-defined search paths correctly, then
    #include "string.h"
refers to the file in your project, and
    #include <string.h>
refers to the standard header.

Having <string.h> and "string.h" do "totally different things" would
perhaps be unwise, but nothing in the standard forbids it.  (I wonder
if you think it could or should.)

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

No they wouldn't -- or rather, no they don't.  A program that carelessly
uses #include "string.h" to refer to the standard header will work just
fine as long as the project doesn't have a file by that name.  The
initial search will fail, and then it will find the standard header.
Certainly #include <string.h> is better style.  And a program that
deliberately uses #include "string.h" to refer to its own file by that
name, it will work correctly as long as the search path is set up
correctly.

I'm personally not entirely comfortable with mirroring standard header
names, like using #include "string.h" to use a header file that wraps
the standard header <string.h>.  My first thought on seeing that would
be to think that the author should have used <> rather than "".  There's
also some risk that if you don't set up the search path correctly,
#include "string.h" could refer to the standard header.  But I can see
how it would be useful, and nothing in the language forbids it.  If a
project uses such a scheme consistently, I have no problem with it,
beyond a brief moment of "Oh, that's what you're doing".

I might prefer #include "string_wrapper.h".

[snip]

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