«

"Russell Shaw" <rjshawN_o@s_pam.netspace.net.au> wrote in message
news:l99ct9-...

> extern int a;
> static int a;
>
> I get: error: static declaration of 'a' follows non-static declaration
>
>
> In WG14/N1256, 6.2.7 p4 seems to say this should not be an error.

Are you debugging an actual program, or the C standard?!

At file-scope, "extern int a" might be compatible with an "int a" in the
same module, but not with "static int a" (I'm sure you know the meanings of
all these). So the error message is justified.

--
Bartc

"BartC" <> writes:

> "Russell Shaw" <rjshawN_o@s_pam.netspace.net.au> wrote in message
> news:l99ct9-...
>
>> extern int a;
>> static int a;
>>
>> I get: error: static declaration of 'a' follows non-static declaration
>>
>>
>> In WG14/N1256, 6.2.7 p4 seems to say this should not be an error.
>
> Are you debugging an actual program, or the C standard?!
>
> At file-scope, "extern int a" might be compatible with an "int
> a" in the same module, but not with "static int a" (I'm sure
> you know the meanings of all these). So the error message is
> justified.

If you consult 6.2.2 p4 you will see that there is more to
the story than complete non-compatibility.

On 01/26/2013 10:14 AM, BartC wrote:
> "Russell Shaw" <rjshawN_o@s_pam.netspace.net.au> wrote in message
> news:l99ct9-...
>
>> extern int a;
>> static int a;
>>
>> I get: error: static declaration of 'a' follows non-static declaration
>>
>>
>> In WG14/N1256, 6.2.7 p4 seems to say this should not be an error.
>
> Are you debugging an actual program, or the C standard?!
>
> At file-scope, "extern int a" might be compatible with an "int a" in the
> same module, but not with "static int a" (I'm sure you know the meanings of
> all these). So the error message is justified.

That explanation suggests that the error message would be equally
justified if the order of the declarations were reversed. See the other
messages on this thread for the details of why that's wrong.
--
James Kuyper

"Tim Rentsch" <> wrote in message
news:...
> "BartC" <> writes:
>
>> "Russell Shaw" <rjshawN_o@s_pam.netspace.net.au> wrote in message
>> news:l99ct9-...
>>
>>> extern int a;
>>> static int a;
>>>
>>> I get: error: static declaration of 'a' follows non-static declaration
>>>
>>>
>>> In WG14/N1256, 6.2.7 p4 seems to say this should not be an error.
>>
>> Are you debugging an actual program, or the C standard?!
>>
>> At file-scope, "extern int a" might be compatible with an "int
>> a" in the same module, but not with "static int a" (I'm sure
>> you know the meanings of all these). So the error message is
>> justified.
>
> If you consult 6.2.2 p4 you will see that there is more to
> the story than complete non-compatibility.

But then 6.2.2 p7 appears to contradict that.

--
Bartc

On 01/26/2013 01:21 PM, BartC wrote:
>
>
> "Tim Rentsch" <> wrote in message
> news:...
>> "BartC" <> writes:
>>
>>> "Russell Shaw" <rjshawN_o@s_pam.netspace.net.au> wrote in message
>>> news:l99ct9-...
>>>
>>>> extern int a;
>>>> static int a;
>>>>
>>>> I get: error: static declaration of 'a' follows non-static declaration
>>>>
>>>>
>>>> In WG14/N1256, 6.2.7 p4 seems to say this should not be an error.
>>>
>>> Are you debugging an actual program, or the C standard?!
>>>
>>> At file-scope, "extern int a" might be compatible with an "int
>>> a" in the same module, but not with "static int a" (I'm sure
>>> you know the meanings of all these). So the error message is
>>> justified.
>>
>> If you consult 6.2.2 p4 you will see that there is more to
>> the story than complete non-compatibility.
>
> But then 6.2.2 p7 appears to contradict that.

Only because the extern declaration occurs first. If the order were
reversed, then because of 6.2.2p4, both declarations would give it
internal linkage, and 6.2.2p7 wouldn't apply.
If it was simply a matter of the two declarations being incompatible,
the relative order of the declarations wouldn't matter.
--
James Kuyper

"James Kuyper" <> wrote in message
news:ke19dv$m45$...
> On 01/26/2013 01:21 PM, BartC wrote:

>> "Tim Rentsch" <> wrote in message

>>> If you consult 6.2.2 p4 you will see that there is more to
>>> the story than complete non-compatibility.
>>
>> But then 6.2.2 p7 appears to contradict that.
>
> Only because the extern declaration occurs first. If the order were
> reversed, then because of 6.2.2p4, both declarations would give it
> internal linkage, and 6.2.2p7 wouldn't apply.
> If it was simply a matter of the two declarations being incompatible,
> the relative order of the declarations wouldn't matter.

OK, C declarations are more messed up than I thought. (I knew it was a
mistake to actually look at the standard!)

So, a static identifier is static.

But an extern identifier might also be static, depending on something in the
source code a thousand lines back, hidden in a 5-deep include file.

As for identifiers which are not static, and not extern (ie. defined here
and exported from this module), I've no idea now how they fit into the
picture. Unless they have to pretend to be extern too. (Then, in the absence
of one module claiming ownership by initialising the associated object, the
linker might be kind enough to define it anyway.)

(I try to impose a simpler model on my function identifiers in C:

global functions - defined here and exported
local functions - defined here and only used here
external functions - defined elsewhere but imported for use here

And the way I use C, I only need to write global or local function
definitions; no extern declarations or prototypes are needed.

Applying the same model for variables is a little trickier, and for those I
do have to declare global variables twice (as extern, and again as global).
I understand that behind the scenes, C does unsavoury things such as
allowing an extern declaration to be followed by a global definition, but I
try to put that out of my mind. Now it seems it does even more stuff I have
to steer well clear of...)

--
Bartc

On 01/26/2013 04:59 PM, Richard Damon wrote:
> On 1/26/13 4:22 PM, BartC wrote:
>
>> (I try to impose a simpler model on my function identifiers in C:
>>
>> global functions - defined here and exported
>> local functions - defined here and only used here
>> external functions - defined elsewhere but imported for use here
>>
>> And the way I use C, I only need to write global or local function
>> definitions; no extern declarations or prototypes are needed.
>>
>
> It is very hard to use a global function from another translation unit
> without a extern (prototype) definition. (It was allowed in C90 under
> limited conditions, but becomes a constraint error in C99 and later).

I think you're confusing function definitions with function
declarations. A function definition has always been necessary for a
successful function call. However, in C99, having a function declaration
visible in the current scope became mandatory - that may be what you're
thinking about.
Also, a function declaration doesn't have to be a function prototype.
Non-prototype function declarations are still supported as of C2011.
--
James Kuyper

On 01/26/2013 04:22 PM, BartC wrote:
....
> As for identifiers which are not static, and not extern (ie. defined here
> and exported from this module), I've no idea now how they fit into the
> picture. ...

Because of the multiple meanings attached to the 'static' keyword by the
C language, it's best to avoid using 'static' as an adjective all by
itself. The relevant phrases are "internal linkage", "external linkage",
and "no linkage", "static storage duration" and "automatic storage
duration" (there are other storage durations, but they're not likely to
be relevant in this context).

Could you describe the category you're talking about in those terms?

By "not static, and not extern", do you mean identifiers declared
without using either of those keywords? If so, there's some simple rules:
If it identifies a function, it has external linkage. If it identifies a
file scope object it has external linkage and static storage duration.
If it identifies a block scope object it has no linkage, and automatic
storage duration. In all other cases, the identifier has no linkage and
no associated storage, so it therefore has no associated storage duration.

Or, by "not static, and not extern", do you mean identifiers with
neither internal nor external linkage? If so, they're an extremely
diverse group, which means that there's very little that can usefully be
said about the entire group. They include all struct, union, and enum
tags and members. They include macro names, statement labels, typedef
names, function parameter names, and all variables declared with block
scope and without 'extern'.

Or, by "not static, and not extern", do you mean identifiers with
neither static storage duration nor external linkage? That's an even
larger group, and there's corresponding less that can be usefully said
about it the entire group.

> ... Unless they have to pretend to be extern too. (Then, in the absence
> of one module claiming ownership by initialising the associated object, the
> linker might be kind enough to define it anyway.)

The comment about "pretend to be extern" suggests to me that you may be
referring to identifiers declared without the 'extern' keyword. Some of
those identifiers do have external linkage - there's nothing "pretend"
about it, but there is something implicit about it.

....
> And the way I use C, I only need to write global or local function
> definitions; no extern declarations or prototypes are needed.

In C, you can avoid writing declarations with external linkage only by
keeping all of the functions in your program in a single module.
However, it's entirely normal to not have any need to write declarations
using the 'extern' keyword, because functions implicitly have external
linkage unless specified otherwise.
--
James Kuyper

"Richard Damon" <> wrote in message
news:LkYMs.356815$...
> On 1/26/13 4:22 PM, BartC wrote:

>> And the way I use C, I only need to write global or local function
>> definitions; no extern declarations or prototypes are needed.
>>
>
> It is very hard to use a global function from another translation unit
> without a extern (prototype) definition. (It was allowed in C90 under
> limited conditions, but becomes a constraint error in C99 and later).

(The extern declarations are there, but I don't write them myself. My C
source is pre-processed before compiling, and a file of exported functions,
and one of local function prototypes, are created, which are then included
in the right places.

For this purpose it was simplest to use a keyword or two before each
function definition to make them easier to pick out (so they will have
'function' or 'global function' in front). It just makes life much easier!
And I don't need to keep 6.2.2 in mind all the time either (and before today
I'd never heard of it).

I expect development tools such as C IDEs also have plenty of such features
to make coding simpler.)

--
Bartc

"James Kuyper" <> wrote in message
news:ke1n9s$b13$...
> On 01/26/2013 04:22 PM, BartC wrote:
> ...
>> As for identifiers which are not static, and not extern (ie. defined here
>> and exported from this module), I've no idea now how they fit into the
>> picture. ...
>
> Because of the multiple meanings attached to the 'static' keyword by the
> C language, it's best to avoid using 'static' as an adjective all by
> itself. The relevant phrases are "internal linkage", "external linkage",
> and "no linkage", "static storage duration" and "automatic storage
> duration" (there are other storage durations, but they're not likely to
> be relevant in this context).
>
> Could you describe the category you're talking about in those terms?
>
> By "not static, and not extern", do you mean identifiers declared
> without using either of those keywords?

> Or, by "not static, and not extern", do you mean identifiers with
> neither internal nor external linkage? If so, they're an extremely
> diverse group, which means that there's very little that can usefully be
> said about the entire group. They include all struct, union, and enum
> tags and members. They include macro names, statement labels, typedef
> names, function parameter names, and all variables declared with block
> scope and without 'extern'.
>
> Or, by "not static, and not extern", do you mean identifiers with
> neither static storage duration nor external linkage? That's an even
> larger group, and there's corresponding less that can be usefully said
> about it the entire group.

Sorry, I thought I was being obvious. But perhaps there is something about
the terms 'extern' and 'external linkage' as used by C that I'm missing. To
me, 'external' means something that is imported. What I referred to as
'static' were things that are neither imported nor exported (ie local). The
last group, 'not static and not extern', I mean names that are exported.

Examples showing how my various groups are expressed in normal C (in my
preprocessed version, I make them more obvious):

local static int fna(void){}
exported int fnb(void){}
imported extern fnb(void);
or implicit

So imported, exported, or local. I would guess that C uses 'extern' to mean
both imported and exported names (fnb and fnc in my table).

I'm also talking about objects which, when exported or imported, need the
linker's help to achieve that. Not about structs, unions, enums, macros, or
typedefs, which can easily shared across modules simply by duplicating their
definitions in each module (by them appearing in a common header file for
example).

--
Bartc