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: Mon, 30 Mar 2026 08:19:52 -0700 Organization: A noiseless patient Spider Lines: 101 Message-ID: <86a4vp1h0n.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Mon, 30 Mar 2026 15:19:54 +0000 (UTC) Injection-Info: dont-email.me; posting-host="2cd52f7e7f6c86e7548f05bf3bc2e07a"; logging-data="2644421"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+smf7qlBa2tDpTYprR/DbL5oXiYG/S2qs=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:czU7qKg0GCMRQxUcXLwnb2S/kso= sha1:LFRM/2TKLGkw6Jg4IFjBfla84R8= Xref: csiph.com comp.lang.c:397309 Michael S writes: > On Fri, 27 Mar 2026 09:03:23 -0700 > Tim Rentsch wrote: > >> Michael S writes: >> >>> On Thu, 26 Mar 2026 19:08:16 -0700 >>> Tim Rentsch wrote: >>> >>>> Michael S writes: >>>> >>>>> On Thu, 26 Mar 2026 22:36:59 +0000 >>>>> Bart wrote: >>>>> >>>>>> Take this program: >>>>>> >>>>>> #include >>>>>> >>>>>> inline int F(){return rand();} >>>>>> >>>>>> int main(void) { >>>>>> return F(); >>>>>> } >>>>>> >>>>>> This compiles fine with gcc using -O1 -O2 -O3. >>>>>> >>>>>> But compile without optimising, and it fails to link as it >>>>>> can't find a function 'F'. >>>>>> >>>>>> Is it supposed to behave like that? I assume no discrete >>>>>> function F is being generated because of the 'inline' >>>>>> attribute, but you'd think it would ignore that if >>>>>> inlining wasn't enabled. >>>>>> >>>>>> [...] >>>>> >>>>> Sounds like a bug introduced during transition to c99/gnu99 >>>>> front end. >>>>> With gcc4.x, which defaults to gnu89 it still works. >>>>> Also works with the latest gcc -std=gnu89 >>>>> But there is no hope that gcc maintaines will ever admit that it >>>>> is a bug. >>>> >>>> It isn't a bug. The C standard allows this behavior. >>> >>> So, by C standard, there is no situation in which 'inline' >>> with no addition qualifuers like 'static' or 'extern' can be >>> used with predictabe outcome? >> >> That depends on just how you mean the question. If we have this >> source file >> >> inline int >> F(){ >> return 0; >> } >> >> int >> main(void){ >> return F(); >> } >> >> then we might get an undefined reference for F(). However if we >> expand that source file just slightly, to >> >> inline int >> F(){ >> return 0; >> } >> >> int >> main(void){ >> return F(); >> } >> >> int F(); >> >> then the program has well-defined behavior. This result obtains >> because the function F() now has a declaration that is (implicitly) >> external, and without specifying 'inline', in addition to the >> original inline definition. > > It is indeed well-defined. But well-defined behavior does not > match the most probable intention of programmer, which is to > create a body of F() in case that it was not actually inlined and > to *not* create it otherwise. I simply disagree. The behavior you describe is what people expect for static inline functions. It doesn't make sense that they would expect the same thing for non-static inline functions, if they had taken some time to think about it. > For something like MSVC it does not matter, because by default it > does not link unused functions into executive. But something like > gcc by default links everything in. That depends on what you mean by "by default". gcc does not produce an actual function body for any optimization level above -O0. Surely the most common practice these days is to enable some optimization level above -O0.