Path: csiph.com!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Experimental C Build System Date: Sat, 03 Feb 2024 13:51:07 -0800 Organization: None to speak of Lines: 48 Message-ID: <87v875md2s.fsf@nosuchdomain.example.com> References: <87r0hvpxx8.fsf@nosuchdomain.example.com> <87frybprp3.fsf@nosuchdomain.example.com> <87bk8zpnxx.fsf@nosuchdomain.example.com> <87h6iqo1cq.fsf@nosuchdomain.example.com> <86y1c27wum.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: dont-email.me; posting-host="026cbd12272797f54d5c091ea0e8c8d6"; logging-data="3473395"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18lF46UaAZU51/vMdHAMCBx" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:OZyjY4kHrB9rVk9SqU6fdXHMDTM= sha1:8b++EEIimX0nf+/1WBCEWVUQqhg= Xref: csiph.com comp.lang.c:381708 Tim Rentsch writes: > Keith Thompson writes: >> Lawrence D'Oliveiro 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 ; >> 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 > form). A #include 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). On further thought, I tend to agree. I was thinking that an implementation could usefully provide some of its own headers as something other than files, as it's clearly allowed to do for the C standard headers. But the obvious way to do that would be to require such headers to be included with <>, not "". POSIX-specific headers like unistd.h are already conventionally included with <>. An implementation probably *could* bend the meaning of "file" enough to support having `#include "whatever.h"` load something other than a file in the host filesystem, but it's not as useful as I first thought it might be -- and it could interfere with user-provided header files that happen to have the same name. -- 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 */