[Expat-bugs] [ expat-Bugs-669861 ] storeRawNames and namespace processing

SourceForge.net noreply at sourceforge.net
Fri Jan 17 10:19:42 EST 2003

Bugs item #669861, was opened at 2003-01-17 12:52
You can respond by visiting: 

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Pavel Hlavnicka (pavel_hlavnicka)
Assigned to: Nobody/Anonymous (nobody)
Summary: storeRawNames and namespace processing

Initial Comment:
I'm really not sure it is really a bug, so forgive me,
if I'm wrong.

I think, there is a bug in the storeRawNames procedure,
where this code is executed:

tag->buf = temp;
tag->name.str = (XML_Char *)temp;

It makes buf and name.str the same, and the value is
unexpanded tag name (like UML:Multiplicity in my case).

It is in contradiction with what is set to name.str,
when namespace processing is active and the
storeAttributes method (good camouflage :) concatenates
qname uri, separator and local name set as name.str.

As the values of name.strLen and name.uriLen are kept,
there may a rare error occure in doContent
(XML_TOK_END_TAK) is executed, namely the fragment:

uri = (XML_Char *)tag->name.str + tag->name.uriLen;
while (*localPart) *uri++ = *localPart++;

Under certain conditions both of uri and local part
points the same buffer, and uri points behind the local
name, what results to the overriding of the terminal
zero and endless pattern is copied into the memory
until segfault tells its last word.

As I said, I wish to be more exact, but I believe, my
observations are correct.

Unfortunately, I didn't succeed to create just sample
program, all is happening just in the complex program
(Sablotron), so i'm not 100% it's just a side-effect of
my fault somewhere else. Accept my appology in such a case.

Keep a good work


>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-17 13:19

Logged In: YES 

Which version are you talking about?
Does this problem exist with the current CVS?


You can respond by visiting: 

More information about the Expat-bugs mailing list