Groups | Search | Server Info | Login | Register
Groups > comp.lang.c > #397310
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: gcc and 'include' |
| Date | 2026-03-30 08:27 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <865x6d1gnq.fsf@linuxsc.com> (permalink) |
| References | (6 earlier) <10q96uf$rjbn$1@dont-email.me> <10q9t6d$2p36t$1@paganini.bofh.team> <10qc632$1uds9$1@dont-email.me> <86mrzp1oql.fsf@linuxsc.com> <10qdujq$2g7uj$1@dont-email.me> |
Bart <bc@freeuk.com> writes:
> On 30/03/2026 13:33, Tim Rentsch wrote:> Bart <bc@freeuk.com> writes:
>
>>> On 29/03/2026 00:53, Waldek Hebisch wrote:
>>>
>>>> Bart <bc@freeuk.com> wrote:
>>>>
>>>>> That you declare 'abc' as something to be imported, yet in the next line
>>>>> it is initialised as though it was exported.
>>>>
>>>> Well, C is not able to directy express notion of export and import.
>>>> Also, C does not have modules/interfaces etc. Instead C object
>>>> may be global (which is specified by 'extern' or by lack of storage
>>>> class at file scope) or local. C rules allow you to emulate
>>>> modules using header files. Namely, in header file you put
>>>> 'extern' declaration for exports of given module. Any user of
>>>> of the module must include the corresponding header file.
>>>> To ensure consistency also implementation of the module should
>>>> include the header file. So everywhere elso you have just
>>>> 'extern' declaration, but in implementation there is 'extern'
>>>> declaration first followed by the definition. If such
>>>> sequence was disallowed, then it would be harder to check
>>>> consistency of implementation and corresponding header.
>>>>
>>>> So in reasonable code 'extern' really means "part of interface"
>>>> without specifying if it is import or export.
>>>
>>> But, the rules are lax, and implementations exploit that by all
>>> behaving a little differently.
>>
>> The rules are not lax; they are carefully and precisely defined.
>> To see that one needs to know what the rules are, which in turn
>> depends on reading and understanding the C standard.
>
> The rules may well be precise, but they can also allow for laxity in
> how code is written, and how strictly they are enforced by a compiler.
>
> That is why exactly the same program can pass with 0 warnings or
> errors, pass with some warnings, or fail with errors, depending on the
> options provided. So:
>
> c:\cx>gcc mcc.c
>
> c:\cx>gcc -Wall -Wextra -Wpedantic -O2 mcc.c 2>errors
>
> The first invocation compiled fine. The second generated thousands of
> warnings, for the same language standard. With -Werror, it would also
> fail.
>
> Does the standard also say anything about linking? These two modules:
>
> a.c: int abc; int main(){}
> b.c: int abc;
>
> both individually compile with no problems. They also link
> successfully using TCC and DMC /C/ compilers.
>
> But gcc (invoking its linker) fails saying there are multiple
> definitions of 'abc'.
>
> The point is that a.c + b.c can either form a valid program or not due
> to laxness in the language.
>
> Here's another example which I believe you brought up:
>
> static void F();
> void F() {}
>
> That first 'static' is what determines F's linkage. However someone
> perusing the source code will see 'void F(){...}` and assume it is
> exported.
>
> But you can also have:
>
> static void F(int a);
> static void F(int b);
> static void F(int c);
> extern void F(int d) {}
> static void F(int e);
> void F(int f);
> static void F(int g);
>
> This is what I call being lax, while still within the rules, whatever
> they are.
>
> (In my language, F must be defined in exactly one place. No other
> declarations are allowed or needed within the program itself. So such
> multiple instances don't arise.
>
> It is effectively stricter than C but enforced through better
> design. C's design could also be tightened up, but people don't seem
> to like losing the 'flexibility' shown above.)
It seems to me that your real complaint is not that you don't
understand the rules but that you don't like them. I'm not able
to help you with that.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar
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