Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: gcc and 'include'
Date: Fri, 27 Mar 2026 09:03:23 -0700
Organization: A noiseless patient Spider
Lines: 124
Message-ID: <86jyux2ras.fsf@linuxsc.com>
References: <10q4ceb$38i2d$1@dont-email.me> <20260327041042.00006946@yahoo.com> <86wlyy2fe7.fsf@linuxsc.com> <20260327164757.00001882@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Fri, 27 Mar 2026 16:03:26 +0000 (UTC)
Injection-Info: dont-email.me; posting-host="606171d349eb5423921af05ed404581c"; logging-data="4073307"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/QV6V0K2Ct9nzlMSOx1ofSpN2198OZT44="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:hzSwE5M/N8viB3Q4rqhyNlJewRQ= sha1:tw/W/Gt8Kot/BNP8WwzQ1ES2eDw=
Xref: csiph.com comp.lang.c:397227

Michael S <already5chosen@yahoo.com> writes:

> On Thu, 26 Mar 2026 19:08:16 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Thu, 26 Mar 2026 22:36:59 +0000
>>> Bart <bc@freeuk.com> wrote:
>>>
>>>> Take this program:
>>>>
>>>>    #include <stdlib.h>
>>>>
>>>>    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.

The usual pattern for providers of inline functions is supply a home
for any inline functions defined in the .h file, by putting a
non-line declaration in the corresponding .c file.  Here is a simple
example:


  in inline-client.c:

      #include "f-provider.h"

      int
      main(){
          return  F();
      }


  in f-provider.h:

      #ifndef H_f_provider_h_
      #define H_f_provider_h_

      inline int
      F(){
          return  0;
      }

      #endif/*H_f_provider_h_*/


  in f-provider.c:

      #include "f-provider.h"

      int F();


Following this pattern provides a definition for function F() with
external linkage -- in f-provider.o -- in case one is needed.

Note that this pattern can be used regardless of whether the inline
definition for F() in the .h file specifies 'static' or doesn't.

For what it's worth, I agree the rules for inline functions that do
not specify 'static' are kind of weird.  I don't know what the
rationale was for choosing them.  However, once one knows the
pattern for how to deal with such cases, it's easy to provide inline
functions without the danger of getting undefined references.