Value of Un-initialized Stack Variable in OSX

[prateek86400]

If you check the value of an un-initialized stack variable in OSX, its
always zero. This isn't true for Windows or Linux. Does anybody know
why ?

 

[Ben Bacarisse]

If you check the value of an un-initialized stack variable in OSX, its
always zero.

How do you know? Have you really checked them all? Some have not
even been allocated yet.

This isn't true for Windows or Linux. Does anybody know
why ?

Asking about this supposed difference is all very well provided that
you never write any code that relies on the answer.

 

[Flash Gordon]

If you check the value of an un-initialized stack variable in OSX, its
always zero.

Wat do you mean, always?

Mark-Gordons-MacBook-Air:~ markg$ cat t.c
#include <stdio.h>

void test(void)
{
int a;
printf("a= %d\n",a);
a=42;
}

int main(void)
{
test();
test();
return 0;
}
Mark-Gordons-MacBook-Air:~ markg$ gcc t.c
Mark-Gordons-MacBook-Air:~ markg$ ./a.out
a= 4096
a= 42
Mark-Gordons-MacBook-Air:~ markg$

Two values neither of which is 0.

This isn't true for Windows or Linux. Does anybody know
why ?

Because they don't initialise them.

If you want a variable to have a value then give it one.

 

[Richard Tobin]

A number of implementations choose to zero-initialize uninitialized
stack variables. Some do this for debugging reasons.

In many implementations the stack will contains zeros when first
mapped in, so early procedure calls will see uninitialised stack
variables as zero, but later ones will see whatever earlier ones left
there. On SunOS, several programs that were relying on variables in
main() being zero were found when shared libraries were introduced,
because they are loaded by code run before main().

-- Richard

 

[Keith Thompson]

Yes. UNIX vs. Windows vs. Linux. Read those standards documents if
you want to know why. Has nothing to do with the C language.

Really? Are you saying that one of those standards requires
uninitialized automatic objects ("stack variables") to be set to zero?
I'm skeptical.

It's more likely that variables are being set to zero by coincidence,
and that search standards documents (assuming you can find them) is
going to be a waste of time. It's also possible that a particular
compiler might generate code that implicitly initializes such objects
to zero, but I doubt it.

 

[Keith Thompson]

In any OS considered to be secure (as defined by the US govt, not M$), there
is no possibility that the stack (or any other memory such as the "heap")
would contain information left behind by any other processes. It might not
be initialized to 0, but it wouldn't exactly be random either.

That's a good point, but was it intended to be an answer to my
question?

 

[Keith Thompson]

Apparently you have done very little real world programming where
you were porting something and ever had to figure out why something
that works on one machine doesn't work on another that involved a
not explicitly initialized variable. Just file this away if you
ever have to port something that was made to run specifically on one
system and only one system to another. The lack of explicit
initialization may not be an error for that system. (Doesn't mean
the original author shouldn't be strangled if he didn't comment it.)

The OP's problem was that stack variables were being set to zero on
one system but not on others. Your advice was to check the standards
documents for UNIX, Windows, and/or Linux. That advice might be valid
*if* those documents specifically require uninitialized stack
variables to be set to zero. I don't believe that they do, and I
believe that following your advice would therefore be a collosal waste
of time.

There might well be valid reasons why stack variables are implicitly
initialized to zero on some system, but fixing the code is likely to
be a better use of the OP's time than tracking down the reason.

If I'm wrong, prove it. Bonus points for doing so without snide
remarks about my alleged lack of experience.

As to your comment about compilers, maybe you should look into the default
environment that the compiler is invoked with.

In any case it is all off topic.

It was your advice to check other standards that was off topic, as
well as very likely being incorrect.

 

[Phil Carmody]

Apparently you have done very little real world programming where you were
porting something and ever had to figure out why something that works on one
machine doesn't work on another that involved a not explicitly initialized
variable.

I'd hardly call reading the compiler's warning messages "figuring out".
These are stack variables we're talking about. The static analysis in
practically every compiler I've seen in the last decade will find potential
use of uninitialised variables. (Sometimes even when that potential can
never be realised, alas).

Phil

 

[Richard Tobin]

If you check the value of an un-initialized stack variable in OSX, its
always zero. This isn't true for Windows or Linux. Does anybody know
why ?

[/QUOTE]

Yes. UNIX vs. Windows vs. Linux. Read those standards documents if
you want to know why.

As far as I know, none of those operating systems guarantees that
uninitialised stack variables will be zero.

Some of them may guarantee that the stack initially contains zeros,
but as I pointed out in another article they will not necessarily
still be zero by the time a user function is called.

-- Richard

 

[Amandil]

Yes.  UNIX vs. Windows vs. Linux.  Read those standards documents if
you want to know why.

As far as I know, none of those operating systems guarantees that
uninitialised stack variables will be zero.

Some of them may guarantee that the stack initially contains zeros,
but as I pointed out in another article they will not necessarily
still be zero by the time a user function is called.[/QUOTE]

To clarify, the stack may _initially_ contain all zeros, or a specific
value, when the program is started. That is up to the individual OS's,
and may be found in the documentation. However, whether automatic
variables are initialized is not up to the OS (I don't think it can be
up to the OS). It may be up to the processor, for example, on systems
where a function entry assembler instruction exists. It is up to the
compiler, possibly allowing for different setings. This would (should)
be found in the documentation for each compiler.

Cheers,

--Marty Amandil

 

[Nate Eldredge]

I'd hardly call reading the compiler's warning messages "figuring out".
These are stack variables we're talking about. The static analysis in
practically every compiler I've seen in the last decade will find potential
use of uninitialised variables. (Sometimes even when that potential can
never be realised, alas).

Yeah, the halting problem's a real bummer.

 

[Phil Carmody]

Yeah, the halting problem's a real bummer.

And my mission this week and next is to tackle as many of the 630
outstanding Coverity errors in the kernel. Just a quick peek this
afternoon yielded 4 non-bugs and only one real one. In some ways
it seemed so clever, but those non-bugs were so bleedin' obviously
not bugs that it simultaneously seemed completely dumb. Gonna be
a long 8 days...

Phil