Are you shure MSVC is not optimizing away your asignment?
If the variable is not used in a rather near scope, MSVC does this
sometimes too agressively.
ms
On Wed, 2002-02-06 at 15:34, Cini, Richard wrote:
Hello, all:
I have discovered an interesting anomaly while finishing up the 2.2
version of the Altair32 Emulator (to be released this weekend, by the way).
Maybe it's my lack of understanding of C or the service pack I applied to
MSVC :-)
Between version 2.0 and 2.1, BASIC 3.2 was broken -- it was hanging
in a loop in the console input code waiting for the right status bits to be
set by my port emulator code. While I was setting the right bits, the
internal emulator variable wasn't reflecting the assignment.
In the sio00h routine in the sio.c module, I declare a local-scope
variable of type int that's not initialized...
int sio00h (params...){
int nSioStatus ;
... stuff
}
When in the MSVC debugger, the undeclared variable has the value
0xcccccccc. OK.
In the body of the routine, the variable can be set to three values
using #defines from the header. For some reason, the variable is not being
set to the #define value. As you trace execution, the variable to be
returned by the routine remains 0xcccccccc after assignment:
nSioStatus = SIO_WDB ; //#defines to 0x80
So, I initialized the variable to 0 and for good measure, returned
the int as:
return (nSioStatus & 0xff) ;
In one of the top calling routines, it gets truncated to a BYTE-size
(so to speak) anyway.
So I figured that maybe there was a scoping problem but the
nSioStatus variable is not used in any other module, nor is it declared
extern or module global. The #define appears in multiple headers but are all
defined to be the same value.
Now, BASIC 3.2 it works but I can't really figure out why.
Any thoughts??
Rich
--
Michael Schneider email: ms(a)vaxcluster.de
Germany
http://www.vaxcluster.de
People disagree with me. I just ignore them.
(Linus Torvalds)