external variables

[Larry Gates]

Just wanted to make sure of soemthing and couldn't find it in K&R.

q1) External variables are always initialized. (To zero if not explicitly
initialized to another value.)

q2) External variables are declared in the same file, but outside of any
function.

q3) The one that is actually used for initialization is the one that does
not have the extern attribute.

q4) C requires that one not have the extern attribute, and that all others
do have it.

Thankds for your comment.

 

[Guest]

Just wanted to make sure of soemthing and couldn't find it in K&R.

section 4.3 seems to explain things quite well

q1)  External variables are always initialized.  (To zero if not explicitly
initialized to another value.)  
yes

q2)  External variables are declared in the same file, but outside of any
function.  

"in the same file" as what?

q3)  The one that is actually used for initialization is the one that does
not have the extern attribute.

there can be only one definition in one file. This is in deed the
one that gets initialised and it is not preceeded by the extern
keyword. there can be many declarations in many files and they
must have the extern keyword. The standard is actually a bit looser
than this but you won't go wrong if you follow these rules

q4)  C requires that one not have the extern attribute, and that all others
do have it.

there may be only one definition but multiple declarations.
Variables are no different from functions in this way.

 

[Larry Gates]

You can also have multiple tentative declarations without it:

C:\MinGW\source> gcc pete1.c -Wall -o r.exe

C:\MinGW\source>r
0 is a null pointer constant.
(char *)0 is a null pointer.

C:\MinGW\source>type pete1.c
/* BEGIN new.c */

#include <stdio.h>

extern int one;
int one;
int one = 1;
extern int one;
int one;
int one;
int one;

int
main(void)
{
if (one == sizeof *(one ? 0 : (char *)0)) {
puts("0 is a null pointer constant.");
puts("(char *)0 is a null pointer.");
}
return 0;
}

/* END new.c */

// gcc pete1.c -Wall -o r.exe

C:\MinGW\source>

Thanks, pete, I'm glad that you inparticular commented, because this is
your thing. I'll play with this and see if I can catch up with the nuance.
--
larry gates

It might do what you mean. Personally, I would never mean that if I
could help it.
-- Larry Wall in <[email protected]>

 

[Larry Gates]

section 4.3 seems to explain things quite well

Indeed it does. I was in §4.4. An interesting sentence in the first
paragraph:

In this sense, external variables are analogous to fortran COMMON blocks or
variables in the outermost block in Pascal.

You would never use a common block if cooking from scratch in contemporary
fortran. Modules have replaced them. I've been asking what common blocks
look like in their native habitat (fortran of the seventies) but haven't
quite sorted out the syntax.

yes

I'd heard as much, but why not check on it now.

"in the same file" as what?

I think I know what Glen means here. I'll check. At the end of §4.4, they
contrast two files. I think we assume that all the files we talk about get
linked together. file2 has the defintion of sp, while file one has a
declaration of sp, correct?

there can be only one definition in one file. This is in deed the
one that gets initialised and it is not preceeded by the extern
keyword. there can be many declarations in many files and they
must have the extern keyword. The standard is actually a bit looser
than this but you won't go wrong if you follow these rules

One definition in one project, though, right? The example for §4.3 is the
reverse polish calculator. You would expect one definition for each entity
in main.c, calc.h, stack.o, getop.o or getch.c ?

there may be only one definition but multiple declarations.
Variables are no different from functions in this way.

ok
--
larry gates

Does the same as the system call of that name.
If you don't know what it does, don't worry about it.
-- Larry Wall in the perl man page regarding chroot(2)

 

[Larry Gates]

Also, you can have a declaration with the extern keyword
inside of a function definition.

Well, if you can't declare a function from within a function, what use is
the keyword extern going to do you there?
--
larry gates

I suppose one could claim that an undocumented feature has no
semantics. :-(
-- Larry Wall in <[email protected]>

 

[Richard]

Well, if you can't declare a function from within a function, what use is
the keyword extern going to do you there?

extern is to tell you and the compiler the function exists but is in an
external file.

Frequently (and correctly IMO) modules come with headers which users of
the code in that module pull in. All the function definitions are
externs. e.g I am a function available in an external file to you.

Here is a simple example

http://www.daniweb.com/forums/thread83098.html

 

[Keith Thompson]

Well, if you can't declare a function from within a function, what use is
the keyword extern going to do you there?

You can't *define* a function within a function definition:

void outer(void) {
void inner(void) { } /* ILLEGAL */
}

You can *declare* a function within a function definition:

void func(void) {
extern void external_function(void); /* OK */
}

but it's no necessarily a good idea. Normally function declarations
like this (prototypes) should be in header files, not buried inside
function definitions.

 

[Larry Gates]

You can't *define* a function within a function definition:

void outer(void) {
void inner(void) { } /* ILLEGAL */
}

You can *declare* a function within a function definition:

void func(void) {
extern void external_function(void); /* OK */
}

but it's no necessarily a good idea. Normally function declarations
like this (prototypes) should be in header files, not buried inside
function definitions.

And that extern is necessary there?
--
larry gates

Perl itself is usually pretty good about telling you what you shouldn't
do.
-- Larry Wall in <[email protected]>

 

[Larry Gates]

No, the one that is actually used for non-default initialization is
the one that has an initializer.

If you have:

<file1.c>
#include <stdio.h>
extern int x;
int main(void)
{
printf("x = %d\n", x);
return 0;
}
</file1.c>

<file2.c>
extern int x = 12;
</file2.c>

...and if these are put together in the same program, the output must
be 12.

What is a good way of representing "putting these together?"

I include lines that I call the goocher, which are commented out command
lines. For this one, do we need
// gcc -c file2.c
// gcc file1.c file2.o -o h.exe

 

[Spiros Bousbouras]

What is a good way of representing "putting these together?"

I include lines that I call the goocher, which are commented out command
lines. For this one, do we need
// gcc -c file2.c
// gcc file1.c file2.o -o h.exe

I tend to do gcc file1.c file2.c
Same (apart from the gcc part) works with Sun
Studio 12.

 

[Larry Gates]

I tend to do gcc file1.c file2.c
Same (apart from the gcc part) works with Sun
Studio 12.

I can't tell you how disappointed I was that that doesn't work on
OpenSolaris. I meant SS12, not your goocher.

 

[Larry Gates]

Depends on your tool chain.

For this particular example, I already had the VC++ 2008 IDE open, so
I created a quick project, "inserted" the two source files in the IDE,
built and ran it.

If I'd used a different compiler, the details would vary,

I miss having a pimped-out MS setup. I can see in my mind's eye what that
could be. I usually ran appwizard first.

I'm a non-partaker of the dot.net platform.

 

[Keith Thompson]

And that extern is necessary there?

No.

 

[Guest]

Indeed it does.  I was in §4.4.  An interesting sentence in the first
paragraph:

In this sense, external variables are analogous to fortran COMMON blocks or
variables in the outermost block in Pascal.

You would never use a common block if cooking from scratch in contemporary
fortran.

The original (ed 1) K&R was probably written against a fairly
ancient Fortran.

 Modules have replaced them.  I've been asking what common blocks
look like in their native habitat (fortran of the seventies) but haven't
quite sorted out the syntax.

"GOD IS REAL
-unless a type declaration to the contrary is made"
(Leeds University Comp.Sci. Dept Toilets)

I'd heard as much, but why not check on it now.
what?




I think I know what Glen
Glen?

means here.  I'll check.  At the end of §4.4, they
contrast two files.  I think we assume that all the files we talk about get
linked together.

yes. I'm talking about a single program made up of multiple
compilation units (c files plus their includes). I should have
made that clear.

 file2 has the defintion of sp, while file one has a
declaration of sp, correct?
yes



One definition in one project, though, right?

One definition per program, yes. The so-called "One Definition Rule"
"there shall be one and only one definition of each object or
function"

I'm open toa better phrasing of this

 The example for §4.3 is the
reverse polish calculator.  You would expect one definition for each entity
in main.c, calc.h, stack.o, getop.o or getch.c ?

yes. The ODR.

ok

--
Nick Keighley

"High Integrity Software: The SPARK Approach to Safety and Security"
Customers interested in this title may also be interested in:
"Windows XP Home"
(Amazon)

 

[Larry Gates]

The original (ed 1) K&R was probably written against a fairly
ancient Fortran.

program main
real Z(10,10)
integer a(2,3,4,5)
common /used by lots of people/ a,b,c...z
blah blah
end
subroutine sub1
real Z(10,10)
integer a(2,3,4,5)
common /used by lots of people/ a,b,c...z
common /only used by sub1 and sub2/aa,bb,cc,dd
blah blah
end
subroutine sub2
real Z(10,10)
integer a(2,3,4,5)
common /used by lots of people/ a,b,c...z
common /only used by sub1 and sub2/aa,bb,cc,dd
blah blah
end

I wonder what this would like in C.

One definition per program, yes. The so-called "One Definition Rule"
"there shall be one and only one definition of each object or
function"

I'm open toa better phrasing of this


yes. The ODR.

The ODR. Hmmm. Die Oder demokraticshe republik. Die oder-drehende
Rueckkehr. DeODeRant? Ode to DoD Rants?
--
larry gates

I'm serious about thinking through all the possibilities before we
settle on anything. All things have the advantages of their
disadvantages, and vice versa.
-- Larry Wall in <[email protected]>

 

[Guest]

Note!




The ODR.  Hmmm.  Die Oder demokraticshe republik.  Die oder-drehende
Rueckkehr.  DeODeRant?  Ode to DoD Rants?

http://en.wikipedia.org/wiki/One_Definition_Rule

C++ biased but true of C as well

 

[Boon]

#include <stdio.h>

extern int one;
int one;
int one = 1;
extern int one;
int one;
int one;
int one;

int
main(void)
{
if (one == sizeof *(one ? 0 : (char *)0)) {
puts("0 is a null pointer constant.");
puts("(char *)0 is a null pointer.");
}
return 0;
}

On an unrelated note...

AFAICT, (sizeof *(one ? 0 : (char *)0)) is always 1
(Because the above ?: expression has type char *)

"one" is initialized to 1 "by magic" (i.e. before main)
thus it must (??) be equal to 1 at the start of main.

Therefore, the "as if" rule allows a compiler to remove the test,
which will always evaluate to 1. Correct?

Regards.

 

[Boon]

(one) is initialized as an external object with a value of (1).


Yes.

The type of a conditional expression
which has as its second and third operands:
a null pointer constant
and a pointer,
is the type of the pointer, regardless of the test condition.


The (==) test is not removed.

What do you mean by "is not removed" ?

I'm saying that a compiler /is allowed to/ remove the test.
Do you disagree?

(one) is initialized as an external object with a value of (1).

Therefore, the value of "one" must be 1 at the start of main.

Regards.

 

[Larry Gates]

#include <stdio.h>

extern int one;
int one;
int one = 1;
extern int one;
int one;
int one;
int one;

int
main(void)

What values does one assume as the processor steps through these?
--
larry gates

When in doubt, parenthesize. At the very least it will let some
poor schmuck bounce on the % key in vi.
-- Larry Wall in the perl man page

 

[Nate Eldredge]

What values does one assume as the processor steps through these?

Those are outside any function and don't get executed. On most
machines, the effect of all that nonsense is just that a variable "one"
is created, which is initialized to 1 when the program is loaded (before
main(), in particular).