[Expat-bugs] [ expat-Bugs-824420 ] expat-2003-10-15 - something is broken or at least changed

SourceForge.net noreply at sourceforge.net
Sun Nov 2 03:13:33 EST 2003


Bugs item #824420, was opened at 2003-10-15 17:40
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127

Category: None
Group: Test Required
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Rolf Ade (pointsman)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: expat-2003-10-15 - something is broken or at least changed

Initial Comment:


(.. err, sorry for steppin' in late, again :-( )

I compiled my expat based project with expat-2003-10-15
and run my test suite. 

For at least some rare cases, there seems to be
something broken. I haven't any deep insights, so far,
but since I can't spend much more time at it this night
and in face of the upcomming release, I decided to just
yell, only with an example.

Please download the document
http://www.w3.org/TR/1999/REC-xslt-19991116.xml

If I run 'xmlwf REC-xslt-19991116.xml' I get

REC-xslt-19991116.xml:396:0: unbound prefix

This seems wrong to me in two ways. 

First, without the -n option, xmlwf shouldn't care at
all, if a prefix isn't bound to a namespace. At least
xmlwf 1.95.6 (and prior versions) didn't care (and I
would say, this was right). 

And second, as far as I can tell, the claim itself is
false; there is a xmlns:e namespace declaration in
scope of that element. 

I stumbled over the problem while using the lib and
then tried to reproduce the problem with xmlwf, for
easy demonstration. So, if there is a problem, it's not
with the xmlwf tool, but with the lib itself.

rolf




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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-11-02 03:13

Message:
Logged In: YES 
user_id=3066

Regression test added in tests/runtests.c revision 1.55.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-10-18 02:27

Message:
Logged In: YES 
user_id=3066

Just for the record, here's a more minimal document that
exhibits this problem with the version of Expat before Karl
fixed this bug:

<!DOCTYPE e:element [
  <!ATTLIST e:element
    xmlns:e CDATA "http://example.com/">
  ]>
<e:element/>


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-10-16 10:28

Message:
Logged In: YES 
user_id=290026

Fix committed as xmlparse.c rev.1.116.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-10-16 09:26

Message:
Logged In: YES 
user_id=290026

Rolf, 

I think I was wrong when I said that prefix processing was
always done - it was really only done when
elementType->prefix was non-null despite of ns processing
being turned off. This only happened when the element type 
contained a prefix already in the DTD, as far as I can tell.

That fact that there was no error previously was simply
that the error code for if (!binding) was XML_ERROR_NONE,
which would fail to detect cases in which an error should be
returned.

Once I changed this then it started to return errors when
it should not - as you detected. After looking at that I saw
that the if (elementType->prefix) test was sometimes
positive even if namespaces were turned off, which led
to the error. 

As a result of the one-line change it should actually run
faster now in those rare cases when we have prefixes in the 
DTD.

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

Comment By: Rolf Ade (pointsman)
Date: 2003-10-16 07:15

Message:
Logged In: YES 
user_id=13222


Thanks for the quick patch, Karl!

Your patch fixed the problem with the example document
REC-xslt-19991116.xml. Well, since you said (and your patch
suggests) that up to now expat simply always did ns
checking, even if not asked for, I wonder, why it
hallucinated, that the prefix binding were missing, which is
not the case (as even xmlwf -n itself now - with an
appropiate SYSTEM identifierer or no system identifier) -
confirms). Anyway.

So far, I could not decteced any other problem with the test
suite of my expat pased project.

I also run xmlwf against the OASIS xml test suite (with the
same methodology as in #569461) and found nothing new or
alarming.

Tests, that are still wrong, as in previous versions are

ibm/not-wf/misc/432gewf.xml
sun/not-wf/uri01.xml
xmltest/not-wf/not-sa/010.xml
xmltest/not-wf/not-sa/011.xml

And the debatable
xmltest/not-wf/not-sa/005.xml
which could not counted to the failed tests, because the rec
allows well-formedness parser to fail at this test as well
as to pass it (as already discussed in #569461) - although I
personally feel, that it would be better for the expat
users, if expat would signal error in this cases.

Even a few preliminary benchmark tests haven't showed a
problem (up to now, I don't see any slow down, which would
worth mentioning).


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-10-15 20:41

Message:
Logged In: YES 
user_id=290026

Please try the attached fix: prefix_patch.diff.

The (old) code was processing prefixes even if namespaces
were turned off. Hopefully the changes don't break anything
else. Would be nice if you could run it through the test-suite.

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

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



More information about the Expat-bugs mailing list