Problem with the compiler? Pointers? Unknown.

From: L. Spiro (LSpiro_at_discussions.microsoft.com)
Date: 10/11/04 

Date: Mon, 11 Oct 2004 08:13:02 -0700

Is there a major bug in the Visual C++ .NET compiler version 7.1.3088 or what?

I have created a class that is just a wrapper for other classes. Its only
members are integers and pointers (which will be declared by “new” if it ever
gets that far).

I have one function called FullUnload() which checks the pointers for NULL,
then delete []’s them if they are not. Then it sets them to NULL for the
next time around.
It also sets the integers to 0 and -1.

My constructor sets the pointers to NULL and then calls FullUnload(). This
way the pointers are not deleted, but all the integers are set to their
default 0 or -1.

All of this is perfectly fine, and it is the way it should be. No logical
error here.

But when I run in debug mode, and setp-by-step through the initializing
process, it is total chaos.

m_pMap always starts as 0xFFFFFFFF according to the debugger.
The first step of the constructor is as follows:
m_pMap = NULL;

After this step, guess what m_pMap is?
It’s still 0xFFFFFFFF. Nothing changed at all.

Hit F10 and move on.

It gets to FullUnload() and checks for pointers being NULL before deleting.
The debugger reports m_pMap as being 0xFFFFFFFF still, but it does not try
to delete it.

The next step inside FullUnload() is “m_iTotalMaps = 0;”.

Immediately after, what is m_iTotalMaps? Pick a random number between 16000
and 300000.

The final pointer check in FullUnload() is:

        if ( m_pEnemyModel != NULL ) {
                delete [] m_pEnemyModel;
                m_pEnemyModel = NULL;
        }

The debugger goes:
-> if ( m_pEnemyModel != NULL ) {
-> m_pEnemyModel = NULL;
->Exits FullUnload();

According to the debugger, m_pEnemyModel IS actually NULL, yet it goes
inside the brackets. But when it goes inside it only performs the
“m_pEnemyModel = NULL;” operation. Then it leaves the function.

The worst is yet to come.
To load a map set, I have to create a string for the temporary path.

        char szFinalPath[MAX_PATH] = "";
        strcpy( szFinalPath, g_sDirectory );
        strcat( szFinalPath, "TempScene" );
        //sprintf( szFinalPath, "%sTempScene", g_sDirectory );
        CreateUniqueFileName( szFinalPath );

CreateUniqueFileName() ensures that the file does not exist (and it works
fine).
After leaving this function, szFinalPath is "C:\My
Game\Debug\TempScene344420031919".
Its address is 0x0022F42C.
The next function accepts szFinalPath as a parameter:
void CreateEnemyFile( const char szFinalPath[MAX_PATH], int iIndex );

So I pass it:
        CreateEnemyFile( szFinalPath, 1 );

After leaving this function, szFinalPath is now on address 0x0022F424 (-8
from where it was). CreateEnemyFile() does not have the capability to change
the string it is passed. It is declared with “const”, and there are simply
no changes made to the strings it is passed.

I followed CreateEnemyFile() in the debugger. It was passed the correct
address and it performed its operations fine. When command was returned back
to the calling function, that is when szFinalPath became 8 bytes lower than
it was before, for no reason.

Is this a kernel issue of Windows® XP?
Is this a compiler bug? Is it debugging incorrectly?
Is it not compiling correctly?

The debugger is not only reporting false values but it is following my code
in an illogical and incorrect manner.
Yet the string IS being changed and the functions that use it afterwords are
suffering because of it.

I had “Minimal Rebuild” enabled but disabled it for this testing. No change.

My program is DirectX® and multi-threaded.
The D3DCREATE_MULTITHREADED flag is being passed when creating the device,
and the compiler is set to Multi-threaded Debug (/MTd).
Aside from this new class, all other aspects of my game work like a dream.
But when it comes to this, I do not even know where to begin.

Any ideas at all?

L. Spiro

Relevant Pages

  • Re: new IL: C (sort of...).
    ... only for "recent" Pascals, ... far pointers weren't really limited, ... in my compiler, I made wchar_t a builtin type (in most cases, aliased to ... I could very well include builtin "managed strings" in the new IL. ...
    (comp.lang.misc)
  • Re: new IL: C (sort of...).
    ... and the frontend compiler needs to be able ... Having very limited pointers is a fact of life in a VM language though, ... vague claims about Pascal's pointer support. ... That is pretty normal for standards (the ...
    (comp.lang.misc)
  • Re: code optimiation
    ... Given that the compiler can often optimise the generated code to use the best sized types available, it's seldom worth specifying "fast" types explicitly. ... pointers and floating point types whose "zero value" might not be all- ... instruction, so the assembler produced for *p++ when used as the ... It will do the same job, and let you write the source code using proper array constructs. ...
    (comp.arch.embedded)
  • Re: A taxonomy of types
    ... I am describing how to represent the representation (and, ... if the system follows static typing rules (such as in a compiler), ... so, the hardware sees pointers and pointer arithmetic, but the compiler ... "Besides the char types, up to three sizes of integer, declared short int, ...
    (comp.lang.misc)
  • Re: Whats the position of pointers
    ... The basics ARE simple and ... any teacher worth his salt can get it across with a debugger and an OHP ... Normally one is only interested in ones local implementation. ... Using a debugger in teaching pointers (for C; ...
    (comp.lang.c)
Loading