static initialization

[Darrell Grainger]

Is this a bug in my compiler or am I mistaken?

If I have the following code:

#include <stdio.h>

void test(void)
{
static int i;

printf("%d ", i++);
if(i < 5) test();
}

int main(void)
{
test();
printf("\n");
return 0;
}

If I load and run it I get "0 1 2 3 4 \n" printing out. If I load and
running it a second time I get "5 \n" printing out. I know that &i is the
same on each run of the program. It seems to be retaining the last value
and not clearing the memory location. The fact that I got the correct
output the first time seems like luck.

I thought the standard guarantees that static variables will be
initialized to 0. Am I wrong? Shouldn't this print out the same every
time it is run?

 

[Kevin D. Quitt]

Static within a block is different from static at file scope. Only the
latter is automatically initialized.

 

[Eric Sosman]

Is this a bug in my compiler or am I mistaken?

If I have the following code:

#include <stdio.h>

void test(void)
{
static int i;

printf("%d ", i++);
if(i < 5) test();
}

int main(void)
{
test();
printf("\n");
return 0;
}

If I load and run it I get "0 1 2 3 4 \n" printing out.

That's as expected.

If I load and
running it a second time I get "5 \n" printing out.

That's *not* as expected!

I know that &i is the
same on each run of the program.

Presumably you "know" this by some means external to
the program: documentation, linker maps, or whatever. In
any case, it shouldn't matter whether the `i' locations in
two executions of the program are the same or different: C's
semantics call for the same result no matter the location.

It seems to be retaining the last value
and not clearing the memory location. The fact that I got the correct
output the first time seems like luck.

I'd put it the other way 'round: The fact that you *don't*
get the correct output the second time is luck. Specifically,
bad luck. More specifically, bad luck in using a broken C
implementation.

I thought the standard guarantees that static variables will be
initialized to 0.

It does, in section 6.7.8 paragraph 10 (unless they're
explicitly initialized to something else, of course).

Am I wrong?

No.

Shouldn't this print out the same every
time it is run?

It should, indeed. You have found a bug.

 

[Jeremy Yallop]

Static within a block is different from static at file scope. Only the
latter is automatically initialized.

No, all static duration objects without explicit initializers are
automatically initialized in the same way.

Jeremy.

 

[Alex Monjushko]

Static within a block is different from static at file scope. Only the
latter is automatically initialized.

They are both automatically initialized.

 

[Sam Dennis]

Static within a block is different from static at file scope. Only the
latter is automatically initialized.

Nonsense.

 

[Nick Landsberg]

That's as expected.

I think the keywork here is "load". By this
I presume that when the program exits and you
execute it again, you get the wrong behavior.
(See below for a possible explanation for this bug.)

That's *not* as expected!




Presumably you "know" this by some means external to
the program: documentation, linker maps, or whatever. In
any case, it shouldn't matter whether the `i' locations in
two executions of the program are the same or different: C's
semantics call for the same result no matter the location.




I'd put it the other way 'round: The fact that you *don't*
get the correct output the second time is luck. Specifically,
bad luck. More specifically, bad luck in using a broken C
implementation.




It does, in section 6.7.8 paragraph 10 (unless they're
explicitly initialized to something else, of course).




It should, indeed. You have found a bug.

This may well be a bug not in the compiler but in the
hosted environment (OS). I ran across this only
once before but it drove me crazy since it was not
always reproducible. It was finally tracked down
to improper memory management by the OS where the OS
was using the cached pages of the program image
rather than overwriting them from the disk image
even when you explicitly executed the program again.
This may or may not be the problem in your case.

 

[CBFalconer]

That's as expected.


That's *not* as expected!

.... snip ...

I suspect he is 'running' it under a debugger, and failing to
reset the system. Probably some sort of IDE is involved.

 

[Darrell Grainger]

[snip]

It does, in section 6.7.8 paragraph 10 (unless they're
explicitly initialized to something else, of course).

It should, indeed. You have found a bug.

This may well be a bug not in the compiler but in the hosted environment
(OS). I ran across this only once before but it drove me crazy since it
was not always reproducible. It was finally tracked down to improper
memory management by the OS where the OS was using the cached pages of
the program image rather than overwriting them from the disk image even
when you explicitly executed the program again. This may or may not be
the problem in your case.

Good thing to keep in mind. I usually think about the effects of caching
but didn't today. Mind you, there is no caching or operating system
involved here. The code is generated cross-platform and transferred from
the host computer to the target.

 

[Mark Piffer]

Good thing to keep in mind. I usually think about the effects of caching
but didn't today. Mind you, there is no caching or operating system
involved here. The code is generated cross-platform and transferred from
the host computer to the target.

Just in case you are doing embedded work: often it can be a
(non-intuitive) compiler switch which enables the generation of
initialisation tables because quite often engineers dislike (or simply
lack the possibility of) startup-code. OR you are generating for a
Harvard architecture and the loader only moves the code portion of
your program to the target (happened to me on TI's DSPs). Cross-check
with an initialized global variable which you overwrite in your
program: if that one gets it's proper values everytime before main()
and the static one does not, you can consider your compiler is broken.

Mark