Subj : Re: Win98 error
To   : borland.public.cpp.borlandcpp
From : Bob Gonder <notbg@notmindspring.invalid>
Date : Sat Mar 13 2004 10:05 pm

Ed Mulroy [TeamB] wrote:

>> ... how _this_ module can guarantee that the _other_
>> module has zeroed a global remains a mystery
>
>It is a lot more simple than you would think at first glance.

Yes, point I was obliquely making was they talked about externals
being zero, but the leap of imagination is that _my_ globals are
someone elses externals, so _my_ globals are zeroed. Which they could
have said.  ("Globals and statics are zeroed" vs. "Externals and
statics are zeroed" ) Same thing, but different perspective to my
mind.
IOW "globals are mine, and externals are theirs, so I can rely on
theirs being zero, but not mine."  Course that's not right, but that's
the implication I read if you don't think on it too hard.

Also, there's this mostly forgotten  rememberance back in the DOS days
that some variables started life as zero if you looked at them in
Debug, but not during a normal run. Don't remember the exact
circumstances. Maybe locals? Could be some confusion  in my mind
there.  But, since I never rely on unititialized data, I never have a
problem either.

And, bringing this back full circle..
Ah yes, another point to not rely on globals being zero...unless it's
a one-use routine, the second time through, they aren't.  I think it's
better practice to _always_ initialize variables before you use them
lest you forget when it's actually needed. (I prefer explicit code to
implicit)
OTOH if some other code stepped on my variable, then I'm masking that
error by producing correct results.....

.