Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Experimental C Build System
Date: Sat, 03 Feb 2024 00:53:05 -0800
Organization: A noiseless patient Spider
Lines: 31
Message-ID: <86y1c27wum.fsf@linuxsc.com>
References: <up8i91$h6iu$1@dont-email.me> <up9kc7$mkt1$2@dont-email.me> <up9uuj$rmmf$2@dont-email.me> <upanta$vkgm$1@dont-email.me> <upb9ca$12je5$1@dont-email.me> <upbi8o$14443$1@dont-email.me> <updt7h$1jc8a$1@dont-email.me> <upeab3$1m2f4$1@dont-email.me> <upflbj$202rb$1@dont-email.me> <upfve3$21uv7$1@dont-email.me> <upgcbm$246u1$1@dont-email.me> <upgo72$26abt$1@dont-email.me> <uph2pd$2867k$1@dont-email.me> <uph5vq$28mbj$1@dont-email.me> <87r0hvpxx8.fsf@nosuchdomain.example.com> <uphf0d$29ukk$2@dont-email.me> <87frybprp3.fsf@nosuchdomain.example.com> <uphkt7$2an8i$2@dont-email.me> <87bk8zpnxx.fsf@nosuchdomain.example.com> <upjm2i$2oup9$3@dont-email.me> <87h6iqo1cq.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: dont-email.me; posting-host="86b83c500004563f07cda2ade1e7584b"; logging-data="3221634"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19f/GxMBKGXPVPdZXQ09uw79FXlhe99tY8="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:E6mNgNKCXa4y1WnHogfxLwG+FiA= sha1:GqJtldtg5HLz3jAzQqh5+emHwoU=
Xref: csiph.com comp.lang.c:381663

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote:
>>
>>> A #include directive with <> searches for a "header", which is not
>>> stated to be a file.  A #include directive with "" searches for a file
>>> in an implementation-defined manner;  if that search fails, it tries
>>> again as if <> had been used.
>>
>> The trouble with that interpretation is, it would seem to rule out the use
>> of things like include libraries for user headers.  Do you really think
>> that was the intention?
>
> I don't know.  I imagine an implementation could interpret the word
> "file" to include information extracted from libraries.  Note that it
> doesn't have to correspond to the concept of a "file" used in <stdio.h>;
> that refers to files in the execution environment, not the compilation
> environment.

To me what the C standard says is clear.  A #include "whatever.h"
gets its stuff from a file (assuming of course the appropriate
file can be found, and not revert to the #include <whatever.h>
form).  A #include <whatever.h> gets its stuff from a header,
said header perhaps being stored in a file or perhaps not, and if
file-stored then it could be a 1-1 relationship, or a 1-many
relationship, or a many-1 relationship.  Since the C standard
doesn't define the term 'header', an implementation is allowed to
actualize it however the implementation chooses (including the
possibility of storing information inside the compiler itself).