Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: To include or not to include |
| Date | 2016-09-27 13:53 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <8737klcxma.fsf@bsb.me.uk> (permalink) |
| References | (9 earlier) <ns8i3i$fks$1@dont-email.me> <ns8m5r$sqi$1@dont-email.me> <ns9m0h$fij$1@dont-email.me> <nsbju0$4vl$1@dont-email.me> <nscea2$3fk$1@dont-email.me> |
James Harris <james.harris.1@gmail.com> writes:
> On 26/09/2016 17:55, BartC wrote:
>> On 26/09/2016 00:18, James Harris wrote:
>>> On 25/09/2016 15:15, BartC wrote:
>>
>>>> So it seems superfluous. Unless, for some bizarre reason, you want to
>>>> actually declare a file-scope name inside a function.
>>>
>>> IIRC this goes back to support for single pass. Consider this code:
>>>
>>> int x = 1;
>>> int f(void) {
>>> return x;
>>> }
>>>
>>> When the compiler gets to see x in the function it knows its type.
>>
>> Presumably single passes are still used because C still has trouble with
>> references to functions and variables that occur later on. (Or more
>> likely, it has to maintain that behaviour even though forward
>> declaration requirements could easily be relaxed.)
>
> I think what you wrote in parens is the right interpretation. This is
> about de jure not de facto!
>
>>>> And it doesn't really explain however why 'extern' needs to be used for
>>>> names of file-scope objects and functions that are shared between
>>>> modules.
>>>
>>> From memory I think this is a subtle difference between declarations
>>> (i.e. setting type information) and definitions (reserving storage).
>>> Consider at file scope
>>>
>>> int x;
>>>
>>> Even though that does not assign a value, IIRC the compiler might treat
>>> it as a definition (rules as to when are fiddly). But compare that with
>>>
>>> extern int x;
>>>
>>> The compiler will always see that as a declaration (again, with very
>>> fiddly rules) and not a definition.
>>
>> All C compilers I've tried have no problem with:
>>
>> int x;
>> int x;
>> int x;
>> int x;
>> int x;
>>
>> within the same module, provided only one is initialised.
>>
>> Even when some of these are in other modules: the linker sees multiple
>> instances and creates only one. EXCEPT when I use Tiny C, then it will
>> report multiple definitions of x. That can be fixed by using extern in
>> all either modules except one or even when extern is used everywhere.
>>
>> I don't know if that's a problem with Tiny C, or if it's all the other
>> compilers that are being lax.
>
> I've been reading the standard's /linkage/ section again. It seems to
> be saying that certain identifiers with the same name are merged into
> one (if you like, "linked" together):
You've got to be careful when rewording things. Aj you same, it's the
names that are "merged", but the word "merged" might suggest (as you go
on to say explicitly) that the objects so named are also merged. That's
not the case. The effect of external linkage applied only to the
*declarations* of the names. (Of course, all definitions are also
declarations but not vice-versa.)
> Identifiers with external linkage are merged into one across all the
> translation units that make up a program.
Yes, provided you make it clear that this applies to the declarations.
The definitions of the objects are not merged.
> Identifiers with internal linkage are merged into one within a single
> translation unit.
That's correct, but what gives an identifier internal linkage? Some
people will say "static" and then misunderstand you. Only identifiers
declared at file-scope can be given internal linkage, so static objects
declared in different functions in the same translation unit are not
"merged" because they don't have internal linkage (despite the static
storage class specifier).
> And identifiers with no linkage are not merged. Each one refers to a
> separate entity.
>
> Your "int x" declarations, above, will be external if they are
> declared outside of any function so I think it's correct that they all
> be merged into one.
No. They are all declarations, so the names get "merged", but they are
also definitions (albeit tentative ones) and there must be no more than
one definition of any object (see 6.9).
>>> Oversimplification: Maybe extern declares without reserving storage,
>>> even at file scope.
>>
>> But as I said, you can use only extern, and it will still reserve
>> storage.
If there is no definition of an object there will be no such object. of
course, the behaviour is undefined if the program goes on to use the
object so named which means an implementation is permitted to do what it
likes, including reserving storage for the undefined object, but that
would be odd (and I'd really want to be able to turn that off in order
to see the problem!).
> What I wrote could still be correct, i.e. if the linker reserves the
> storage rather than the compiler doing so.
--
Ben.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
To include or not to include James Harris <james.harris.1@gmail.com> - 2016-09-23 10:45 +0100
Re: To include or not to include David Brown <david.brown@hesbynett.no> - 2016-09-23 12:43 +0200
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-23 12:17 +0100
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-23 13:32 +0100
Re: To include or not to include David Brown <david.brown@hesbynett.no> - 2016-09-23 14:57 +0200
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-24 20:34 +0100
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-24 23:55 +0100
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-25 01:43 +0100
Re: To include or not to include Ian Collins <ian-news@hotmail.com> - 2016-09-25 14:38 +1300
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-25 11:42 +0100
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-25 11:58 +0100
Re: To include or not to include James Harris <james.harris.1@gmail.com> - 2016-09-25 14:06 +0100
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-25 15:15 +0100
Re: To include or not to include Reinhardt Behm <rbehm@hushmail.com> - 2016-09-25 23:33 +0800
Re: To include or not to include Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-09-25 10:04 -0600
Re: To include or not to include Reinhardt Behm <rbehm@hushmail.com> - 2016-09-26 00:21 +0800
Re: To include or not to include "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-25 13:17 -0400
Re: To include or not to include James Harris <james.harris.1@gmail.com> - 2016-09-26 00:18 +0100
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-26 17:55 +0100
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-26 20:07 +0100
Re: To include or not to include supercat@casperkitty.com - 2016-09-26 12:13 -0700
Re: To include or not to include James Harris <james.harris.1@gmail.com> - 2016-09-27 01:25 +0100
Re: To include or not to include supercat@casperkitty.com - 2016-09-26 18:05 -0700
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 14:27 +0100
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-27 14:49 +0100
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 15:15 +0100
Re: To include or not to include Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-27 07:42 -0700
Re: To include or not to include Keith Thompson <kst-u@mib.org> - 2016-09-27 09:30 -0700
Re: To include or not to include Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-27 10:06 -0700
Re: To include or not to include supercat@casperkitty.com - 2016-09-27 08:12 -0700
Re: To include or not to include Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 10:46 -0700
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-27 17:55 +0100
Re: To include or not to include supercat@casperkitty.com - 2016-09-27 10:19 -0700
Re: To include or not to include Keith Thompson <kst-u@mib.org> - 2016-09-27 11:42 -0700
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-27 19:57 +0100
Re: To include or not to include Keith Thompson <kst-u@mib.org> - 2016-09-27 12:38 -0700
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-27 21:00 +0100
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-28 01:50 +0100
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-28 10:55 +0100
Re: To include or not to include Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-27 13:33 -0700
Re: To include or not to include Ike Naar <ike@iceland.freeshell.org> - 2016-09-28 19:13 +0000
Re: To include or not to include supercat@casperkitty.com - 2016-09-27 12:38 -0700
Re: To include or not to include James Harris <james.harris.1@gmail.com> - 2016-09-27 20:57 +0100
Re: To include or not to include supercat@casperkitty.com - 2016-09-27 07:25 -0700
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-28 00:28 +0100
Re: To include or not to include supercat@casperkitty.com - 2016-09-30 07:53 -0700
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-30 16:06 +0100
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 13:53 +0100
Re: To include or not to include James Harris <james.harris.1@gmail.com> - 2016-09-30 19:46 +0100
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-30 20:27 +0100
Re: To include or not to include Reinhardt Behm <rbehm@hushmail.com> - 2016-09-25 23:27 +0800
Re: To include or not to include Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-25 11:38 -0400
Re: To include or not to include Reinhardt Behm <rbehm@hushmail.com> - 2016-09-25 23:40 +0800
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-25 15:06 +0100
Re: To include or not to include Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-25 11:49 -0400
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-25 18:05 +0100
Re: To include or not to include Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-25 16:42 -0400
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-25 21:53 +0100
Re: To include or not to include Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-25 17:57 -0400
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-25 21:20 +0100
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-25 21:49 +0100
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-26 00:40 +0100
Re: To include or not to include David Brown <david.brown@hesbynett.no> - 2016-09-23 14:56 +0200
Re: To include or not to include Richard Heathfield <rjh@cpax.org.uk> - 2016-09-23 13:31 +0100
Re: To include or not to include James Harris <james.harris.1@gmail.com> - 2016-09-23 13:52 +0100
Re: To include or not to include Richard Heathfield <rjh@cpax.org.uk> - 2016-09-23 14:35 +0100
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-23 18:55 +0100
Re: To include or not to include Richard Heathfield <rjh@cpax.org.uk> - 2016-09-23 20:33 +0100
Re: To include or not to include Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-09-23 08:22 -0600
Re: To include or not to include Richard Damon <Richard@Damon-Family.org> - 2016-09-23 11:37 -0400
csiph-web