[Expat-bugs] [ expat-Bugs-667511 ] additional patch for #618199

[SourceForge.net]

Bugs item #667511, was opened at 2003-01-13 20:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=667511&group_id=10127

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Karl Waclawek (kwaclaw)
Summary: additional patch for #618199

Initial Comment:
The attached patch ensures that localPart will point to TAG.buf 
when storeRawNames is called. 
 
There was no need to replace the TAG_NAME.str with the 
keyname for the ELEMENT_TYPE hash entry since the pool 
takes care of deallocating it (keyname) when the pool is 
destroyed. 

----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-14 12:48

Message:
Logged In: YES 
user_id=290026

I looked at storeAtts, and I agree with your assessment.
tag->name.str is always pointing into tag->buf when 
passed to storeAtts() (except for empty elements, but 
for that storeRawnames won't get called).

tag->name.localPart is set to point to tag->name.str 
inside of  storeAtts(). So, if tag->name.str gets 
reassigned inside storeAtts() before assigning it to 
localPart then localPart will not point into tag->buf 
anymore.

I will apply your patch soon.


----------------------------------------------------------------------

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-14 04:16

Message:
Logged In: YES 
user_id=38980

Sorry, I cannot trim a problem to a small test case.  It seems to 
require a certain amount of additional malloc/realloc/free that I 
cannot determine.  I can say that it only happens when doing multiple 
XML_ParseBuffer calls.  Eith debug prints I traced the error to where 
storeRawNames updates the TAG_NAME.localPart.   
 
The problem is that it should only be updated when localPart points 
into tag->buf, which it almost always does.  The exception to this is 
addressed by my patch.  To fix this in storeRawNames would add 
overhead that is not required if TAG_NAME.str is not redefined before 
TAG_NAME.localPart is defined in storeAtts. 

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-13 23:05

Message:
Logged In: YES 
user_id=290026

I think you meant to say:

"The attached patch ensures that TAG_NAME.str will point to
TAG.buf when storeRawNames is called."

Your changes make sense to me, but I am not sure
that there is a bug, since TAG_NAME.str doesn't need
to be updated when it does not point to tag->buf.

Is there a specific case where it fails for you?
If yes, would you please give us the details, so that
we can build a regression test for the patch?

Thanks! 




----------------------------------------------------------------------

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-13 21:34

Message:
Logged In: YES 
user_id=38980

Oops... 
Here is the attachment again 

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-13 21:06

Message:
Logged In: YES 
user_id=290026

Two things:

- I can't see the attachment
- Does this apply to the current CVS?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=667511&group_id=10127