On Thu, 16 Sep 2004 16:59:02 -0700, =Bob=  
<robertUNDERSCOREdobbinsATmailDOTtdsDOTnet> wrote:
> I tried your fix, but it doesn't deal with the missing parameter
> in an ifdef or ifndef for me.


The good news is: I think I may have found the problem.

The bad news is: The fix is not as "clean" as my previous attempt (which I  
now think was wrong, by the way).


It boils down to this:

In the function Parse_Directive, there are a number of clauses (e.g.  
IF_TOKEN, WHILE_TOKEN etc.) that begin with calling Inc_CS_Index() (which  
basically does ++CS_Index). After incrementing CS_Index, it is important  
to assign the correct value to Cond_Stack[CS_Index].Cond_Type before  
calling any parsing functions. Unfortunately, some of those clauses do  
call parsing functions in between incrementing CS_Index and setting  
Cond_Stack[CS_Index].Cond_Type.

The solution is simple, but somewhat tedious: Go through each of those  
clauses and make sure CS_Index is always incremented just before assigning  
to Cond_Stack[CS_Index].Cond_Type. This involves moving about and  
duplicating calls to Inc_CS_Index().


What happens in the test code (the one in Bob's previous posts) is this:

When the macro is invoked, CS_Index is incremented, and Cond_Type set to  
INVOKING_MACRO_COND. When the #end is reached (the one inside the macro),  
CS_Index is decremented. So far so good.
After parsing the #ifdef, CS_Index is incremented, but before Cond_Type is  
set, Parse_Ifdef_Param() is called. Parse_Ifdef_Param finds the #end (the  
one in the scene file), and checks the current (corrupt) Cond_Type. It  
sees that Cond_Type is INVOKING_MACRO_COND (because that happens to be on  
the Cond_Stack due to the macro being called previously), thinks that it  
has reached the end of a macro invokation, and consequently calls  
Return_From_Macro. This results, among other things, in the outermost  
symbol table (in this case, "global identifiers") being destroyed and  
CS_Index being decremented. At this point, the program state is hopelessly  
corrupted, and bad things happen.



-- 
FE

Post a reply to this message

"Fredrik Eriksson" <noo### [at] nowherecom> wrote in message
news:ops### [at] frogeaterbredbandsbolagetse...
[deletions]
: The solution is simple, but somewhat tedious: Go through each of those
: clauses and make sure CS_Index is always incremented just before assigning
: to Cond_Stack[CS_Index].Cond_Type. This involves moving about and
: duplicating calls to Inc_CS_Index(). [more deletions]

Ok Fredrik! Looks like enough info here to for the developers
to work with now, that is, if they have the time. Good sleuthing!
=Bob=

Post a reply to this message