Groups | Search | Server Info | Login | Register


Groups > comp.lang.c > #397227

Re: gcc and 'include'

From Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups comp.lang.c
Subject Re: gcc and 'include'
Date 2026-03-27 09:03 -0700
Organization A noiseless patient Spider
Message-ID <86jyux2ras.fsf@linuxsc.com> (permalink)
References <10q4ceb$38i2d$1@dont-email.me> <20260327041042.00006946@yahoo.com> <86wlyy2fe7.fsf@linuxsc.com> <20260327164757.00001882@yahoo.com>

Show all headers | View raw


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.

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

gcc and 'include' Bart <bc@freeuk.com> - 2026-03-26 22:36 +0000
  Re: gcc and 'include' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-26 16:12 -0700
    Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-27 10:55 +0000
      Re: gcc and 'include' David Brown <david.brown@hesbynett.no> - 2026-03-27 13:49 +0100
      Re: gcc and 'include' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-27 10:51 -0700
      Re: gcc and 'include' Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-27 21:27 +0000
        Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-27 22:05 +0000
          Re: gcc and 'include' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-27 17:03 -0700
          Re: gcc and 'include' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-28 05:10 +0100
          Re: gcc and 'include' Michael S <already5chosen@yahoo.com> - 2026-03-28 20:37 +0300
            Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-28 18:33 +0000
              Re: gcc and 'include' antispam@fricas.org (Waldek Hebisch) - 2026-03-29 00:53 +0000
                Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-29 22:37 +0100
                Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-30 05:33 -0700
                Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-30 14:42 +0100
                Re: gcc and 'include' Michael S <already5chosen@yahoo.com> - 2026-03-30 16:53 +0300
                Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-30 18:11 +0100
                Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-30 08:27 -0700
                Re: gcc and 'include' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-30 11:54 -0700
                Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-30 21:54 +0100
                Re: gcc and 'include' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-30 18:07 -0700
                Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-31 11:39 +0100
                Re: gcc and 'include' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-31 13:56 -0700
                Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-06 20:56 -0700
                Re: gcc and 'include' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-06 23:12 -0700
                Re: gcc and 'include' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-30 21:06 -0400
              Re: gcc and 'include' David Brown <david.brown@hesbynett.no> - 2026-03-29 11:24 +0200
                Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-29 12:44 +0100
                Re: gcc and 'include' David Brown <david.brown@hesbynett.no> - 2026-03-31 15:57 +0200
            Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-30 07:20 -0700
          Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-30 05:07 -0700
  Re: gcc and 'include' Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-27 00:25 +0000
    Re: gcc and 'include' Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-30 07:13 +0000
      Re: gcc and 'include' Andrey Tarasevich <noone@noone.net> - 2026-03-30 07:54 -0700
        Re: gcc and 'include' Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-31 01:46 +0000
          Re: gcc and 'include' antispam@fricas.org (Waldek Hebisch) - 2026-03-31 05:28 +0000
  Re: gcc and 'include' Michael S <already5chosen@yahoo.com> - 2026-03-27 04:10 +0300
    Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-26 19:08 -0700
      Re: gcc and 'include' Michael S <already5chosen@yahoo.com> - 2026-03-27 16:47 +0300
        Re: gcc and 'include' David Brown <david.brown@hesbynett.no> - 2026-03-27 16:43 +0100
        Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-27 09:03 -0700
          Re: gcc and 'include' Michael S <already5chosen@yahoo.com> - 2026-03-29 11:46 +0300
            Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-30 08:19 -0700
              Re: gcc and 'include' Michael S <already5chosen@yahoo.com> - 2026-03-30 20:08 +0300
                Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-31 00:26 -0700
                Re: gcc and 'include' Michael S <already5chosen@yahoo.com> - 2026-03-31 11:27 +0300
                Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-07 09:45 -0700
        Re: gcc and 'include' Andrey Tarasevich <noone@noone.net> - 2026-03-28 10:25 -0700
          Re: gcc and 'include' Michael S <already5chosen@yahoo.com> - 2026-03-29 10:37 +0300
            Re: gcc and 'include' David Brown <david.brown@hesbynett.no> - 2026-03-29 11:30 +0200
            Re: gcc and 'include' Andrey Tarasevich <noone@noone.net> - 2026-03-29 07:22 -0700
            Re: gcc and 'include' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-29 13:56 -0400
              Re: gcc and 'include' Michael S <already5chosen@yahoo.com> - 2026-03-29 21:39 +0300
                Re: gcc and 'include' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-29 20:08 -0400
                Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-30 01:58 +0100
                Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-30 07:59 -0700
  Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-26 19:06 -0700
  Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-27 16:20 +0000
    Re: gcc and 'include' David Brown <david.brown@hesbynett.no> - 2026-03-27 18:07 +0100
    Re: gcc and 'include' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-28 18:48 -0400
  Re: gcc and 'include' Andrey Tarasevich <noone@noone.net> - 2026-03-27 22:38 -0700
    Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-28 00:30 -0700
      Re: gcc and 'include' Andrey Tarasevich <noone@noone.net> - 2026-03-29 16:15 -0700
        Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-30 00:41 -0700

csiph-web