Global variables in modules---preserving values between module calls

[Joseph Wakeling]

Hello all,

I sometimes make use of global variables within modules, which I denote
with "static" so that they will not be seen outside the module, and
will preserve values between module calls.

Recently I was looking back at a rather important function and found
I'd forgotten to put the static declaration in place. I'm not worried
about any interference with outside---the variable names are unlikely
to be reproduced elsewhere---but I am *very* concerned that the values
stored in these variables should have been preserved between module
calls. Else it means I have to throw a lot of data away... :-(

Is this latter feature standard for globals in modules, or is the
"static" designation required here? Certainly the results of the code
would seem to suggest the values were preserved. However, it's not
clear to me that this wasn't just the compiler (gcc -O3 -ansi -pedantic
-Wall ...) being nice to me.

Many thanks,

-- Joe

[Richard Heathfield]

Joseph Wakeling said:

Recently I was looking back at a rather important function and found
I'd forgotten to put the static declaration in place. I'm not worried
about any interference with outside---the variable names are unlikely
to be reproduced elsewhere---but I am *very* concerned that the values
stored in these variables should have been preserved between module
calls. Else it means I have to throw a lot of data away... :-(

File scope objects retain their values, whether they are static-qualified or
not.

3.1.2.4 Storage durations of objects

An object has a storage duration that determines its lifetime.
There are two storage durations: static and automatic.

An object declared with external or internal linkage, or with the
storage-class specifier static has static storage duration. For such
an object, storage is reserved and its stored value is initialized
only once, prior to program startup. The object exists and retains
its last-stored value throughout the execution of the entire
program.

(In your case, the object has external linkage.)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Joseph Wakeling]

Richard Heathfield wrote:

File scope objects retain their values, whether they are static-qualified or
not.

3.1.2.4 Storage durations of objects

An object has a storage duration that determines its lifetime.
There are two storage durations: static and automatic.

An object declared with external or internal linkage, or with the
storage-class specifier static has static storage duration. For such
an object, storage is reserved and its stored value is initialized
only once, prior to program startup. The object exists and retains
its last-stored value throughout the execution of the entire
program.

(In your case, the object has external linkage.)

Great. Thanks very much for the clarification. What is the text that
you quote from?

The external linkage issue is another kettle of fish, or more properly,
can of worms... ;-) Thank God within my own small and fairly limited
code it's never been that much of an issue, and a code error like the
one I described usually has no negative side-effects.

[Vladimir S. Oka]

Joseph Wakeling wrote:

Richard Heathfield wrote:

File scope objects retain their values, whether they are
static-qualified or not.

3.1.2.4 Storage durations of objects

<snip... quote from C Standard>
Great. Thanks very much for the clarification. What is the text that
you quote from?
It's the ISO C Standard. You can buy a PDF of it (around 18 USD, I'm led
to believe), or download N869.pdf (and other formats) which has a very
close draft version, and is free. I don't have links handy, but they've
been mentioned in this group fairly recently. GIYF.
The external linkage issue is another kettle of fish, or more
properly,
can of worms... ;-) Thank God within my own small and fairly limited
code it's never been that much of an issue, and a code error like the
one I described usually has no negative side-effects.

--
BR, Vladimir

Avec!

[Keith Thompson]

"Vladimir S. Oka" <no****@btopenworld.com> writes:

Joseph Wakeling wrote:

Richard Heathfield wrote:

File scope objects retain their values, whether they are
static-qualified or not.

3.1.2.4 Storage durations of objects

<snip... quote from C Standard>

Great. Thanks very much for the clarification. What is the text that
you quote from?

It's the ISO C Standard. You can buy a PDF of it (around 18 USD, I'm led
to believe), or download N869.pdf (and other formats) which has a very
close draft version, and is free. I don't have links handy, but they've
been mentioned in this group fairly recently. GIYF.

Judging by the section number, it's the ANSI C standard of 1989, or a
draft of it. The 1990 ISO standard is functionally identical to the
1989 ANSI standard, but the sections were renumbered; ANSI's section 3
became ISO's section 6.

Officially, the current standard is the 1999 ISO standard (there's no
separate ANSI standard corresponding to this), but the new standard
isn't (yet?) widely implemented.

If you're interested in C99, I suggest n1124.pdf rather than n869.pdf.
n869 is a draft that preceded the approved standard; there were a few
significant changes. n1124 includes the approved C99 standard plus
some changes that have been made since then (TC1 and TC2); the changes
are marked with change bars.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

Keith Thompson wrote:

.... snip ...
Officially, the current standard is the 1999 ISO standard (there's no
separate ANSI standard corresponding to this), but the new standard
isn't (yet?) widely implemented.

If you're interested in C99, I suggest n1124.pdf rather than n869.pdf.
n869 is a draft that preceded the approved standard; there were a few
significant changes. n1124 includes the approved C99 standard plus
some changes that have been made since then (TC1 and TC2); the changes
are marked with change bars.

Except that N869 is available in a text version, and n1124 is not.
For most purposes N869 is quite adequate, and actually
manipulatable with grep etc.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Keith Thompson]

CBFalconer <cb********@yahoo.com> writes:

Keith Thompson wrote:
... snip ...

Officially, the current standard is the 1999 ISO standard (there's no
separate ANSI standard corresponding to this), but the new standard
isn't (yet?) widely implemented.

If you're interested in C99, I suggest n1124.pdf rather than n869.pdf.
n869 is a draft that preceded the approved standard; there were a few
significant changes. n1124 includes the approved C99 standard plus
some changes that have been made since then (TC1 and TC2); the changes
are marked with change bars.

Except that N869 is available in a text version, and n1124 is not.
For most purposes N869 is quite adequate, and actually
manipulatable with grep etc.

For those who don't mind PDF, n1124 is better than n869. (And if you
have the right tools, you should be able to generate plain text from
n1124.pdf.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ico]

CBFalconer <cb********@yahoo.com> wrote:

Except that N869 is available in a text version, and n1124 is not.
For most purposes N869 is quite adequate, and actually manipulatable
with grep etc.

A text-only version is available at http://zevv.nl/div/n1124.txt

--
:wq
^X^Cy^K^X^C^C^C^C

[CBFalconer]

Ico wrote:

CBFalconer <cb********@yahoo.com> wrote:

Except that N869 is available in a text version, and n1124 is not.
For most purposes N869 is quite adequate, and actually manipulatable
with grep etc.

A text-only version is available at http://zevv.nl/div/n1124.txt

Thanks. Unfortunately that needs a lot of work. N869.txt fits on
65 or so char wide pages, and is quite suitable for quote material
in newsgroups.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Ben Bacarisse]

On Fri, 03 Mar 2006 08:14:21 -0800, Joseph Wakeling wrote:

Recently I was looking back at a rather important function and found I'd
forgotten to put the static declaration in place. I'm not worried about
any interference with outside---the variable names are unlikely to be
reproduced elsewhere---but I am *very* concerned that the values stored in
these variables should have been preserved between module calls.

You may well have you answer already, but since C does not have "module
calls" I wanted to check what you really mean. Take, for example:

static int some_data = 42;

int function(void)
{
static int some_other_data = 99;
...
}

In this case, you can "safely" (in your sense) leave off the first static,
but forgetting the second will alter the program's meaning significantly.

--
Ben.