Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: gcc and 'include' Date: Tue, 07 Apr 2026 09:45:34 -0700 Organization: A noiseless patient Spider Lines: 79 Message-ID: <867bqiyb0x.fsf@linuxsc.com> References: <10q4ceb$38i2d$1@dont-email.me> <20260327041042.00006946@yahoo.com> <86wlyy2fe7.fsf@linuxsc.com> <20260327164757.00001882@yahoo.com> <86jyux2ras.fsf@linuxsc.com> <20260329114618.000039da@yahoo.com> <86a4vp1h0n.fsf@linuxsc.com> <20260330200851.00002b49@yahoo.com> <861ph01mum.fsf@linuxsc.com> <20260331112712.00001c72@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Tue, 07 Apr 2026 16:45:41 +0000 (UTC) Injection-Info: dont-email.me; posting-host="578c4ea6691f08c6710ee5a21a69b6e8"; logging-data="3133606"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+6rE2YQQ2+4f9VE5vbkW+L2Aeqzj7VX6s=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:5RBnfB9Syor4CUjFgk9FSEfNsS8= sha1:ZiE/B+DnAxYrOxX54RymvY1vLhA= Xref: csiph.com comp.lang.c:397414 Michael S writes: > Tim Rentsch wrote: >> Michael S writes: >>> Tim Rentsch wrote: >>>> Michael S writes: >>>>> Tim Rentsch wrote: [..in reference to the follwoing translation unit..] >>>>>> inline int >>>>>> F(){ >>>>>> return 0; >>>>>> } >>>>>> >>>>>> int >>>>>> main(void){ >>>>>> return F(); >>>>>> } >>>>>> >>>>>> int F(); >>>>>> [..end excerpt..] >>> In the comment above I was talking specifically about that: >>> https://godbolt.org/z/4TazP4sq1 >> >> I don't know what you were expecting me to learn by looking at >> that page. As far as I can tell it adds no information beyond >> what has already been presented. > > The page shows that when, according to your suggestion, source > code is modified to make it well-defined then body of F() is > generated regardless of optimization level. As you likely > expected. I did expect it, because the C standard requires it. I was simply trying to point out what the C standard requires. > It was a point of suggested modification, was not it? It was not my intention to offer a suggestion. I was only trying to provide information about what the C standard requires. Let me now try to address the second portion of your posting. Here are some excerpts (from your earlier remarks) for context. (The excerpts below may be out of order.) [michael-s] It is indeed well-defined. But well-defined behavior [michael-s] does not match the most probable intention of programmer, [michael-s] which is to create a body of F() in case that it was not [michael-s] actually inlined and to *not* create it otherwise. [michael-s] So, by C standard, there is no situation in which 'inline' [michael-s] with no addition qualifuers like 'static' or 'extern' can [michael-s] be used with predictabe outcome? For inline functions, static inline functions and non-static inline functions serve different purposes. A static inline function is meant to be used to give the compiler discretion as to whether to expand the body inline or to produce a regular static function body, independently, in each translation unit where the function is defined (and presumably called). A non-static inline function is meant to be used where the body may be expanded inline, but it is also important that there be exactly one translation unit where the function is defined as a normal (which is to say, not inline) function, and having external linkage. One reason this might be important is that the address of function will be taken in one or more translation units, and it is important that the address be the same throughout the program. Any programmer understanding to the contrary of these descriptions is at odds with what the C standard says. So I think it's a good idea for anyone with a different understanding to be apprised of what the C standard prescribes, especially if they have definite expectations otherwise.