From noreply at sourceforge.net  Mon Mar  8 20:24:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  8 20:24:07 2004
Subject: [Expat-bugs] [ expat-Bugs-898906 ] Expat fails to correctly parse
	content data
Message-ID: <E1B0VyU-0001qF-00@sc8-sf-web3.sourceforge.net>

Bugs item #898906, was opened at 2004-02-17 09:33
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=898906&group_id=10127

Category: www.libexpat.org
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Expat fails to correctly parse content data

Initial Comment:
In the following XML file:
<?xml version="1.0" ?>
<document>
	<test1 name="if (x<y)" >
	if (x < y)
	</test1>
</document>

the < in the attribute is correctly returned as "<",
however, in the character block, it appears to be 
returned as a NULL.



I will try to look into it to see if I can figure out
where expat went wrong.


Here is the output from my simple test app using expat:

defaultHandler: &#039;<?xml version="1.0" ?&#039;
defaultHandler: &#039;&#039;
startElement &#039;document&#039;
.characterData: &#039;&#039;
.characterData: &#039;&#039;
.startElement &#039;test1&#039;
.Attribute: &#039;name&#039; = &#039;if (x<y)&#039;
..characterData: &#039;&#039;
..characterData: &#039;      if (x&#039;
..characterData: &#039;&#039;
..characterData: &#039; y&#039;
..characterData: &#039;&#039;
..characterData: &#039;&#039;
.endElement &#039;test1&#039;
.characterData: &#039;&#039;
endElement &#039;document&#039;


Thanks,
Nicholas



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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-03-08 17:24

Message:
Logged In: NO 

It is the characterData handler that is not properly
processing the 'less than' sequence. 

If you notice, the 'less than' sequence was properly handled
in the element handler.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-02-25 08:32

Message:
Logged In: YES 
user_id=290026

One thing that comes to mind:

There are two ways of setting a default handler.
One of them suppresses reporting of internal entitities.

Please check the docs and compare with your code.

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

Comment By: Nicholas hendricks (nhendricks)
Date: 2004-02-25 08:24

Message:
Logged In: YES 
user_id=977364

Make that a &lt; where the < is.  
I didn't realize sourceforce would parse the comments,
instead of including them as plain text.

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

Comment By: Nicholas hendricks (nhendricks)
Date: 2004-02-25 08:20

Message:
Logged In: YES 
user_id=977364

I am a sourceforce NOOB, so I cant figure out how to attach
files.

The < in the above example should be <



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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-02-18 07:51

Message:
Logged In: YES 
user_id=290026

The way your document appears here is not well-formed, but
maybe the HTML processing expanded some entities.
Please attach the document as a file.

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

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

From noreply at sourceforge.net  Mon Mar  8 21:36:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  8 21:36:45 2004
Subject: [Expat-bugs] [ expat-Bugs-898906 ] Expat fails to correctly parse
	content data
Message-ID: <E1B0X6m-0006KV-00@sc8-sf-web1.sourceforge.net>

Bugs item #898906, was opened at 2004-02-17 12:33
Message generated for change (Comment added) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=898906&group_id=10127

Category: www.libexpat.org
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Expat fails to correctly parse content data

Initial Comment:
In the following XML file:
<?xml version="1.0" ?>
<document>
	<test1 name="if (x<y)" >
	if (x < y)
	</test1>
</document>

the < in the attribute is correctly returned as "<",
however, in the character block, it appears to be 
returned as a NULL.



I will try to look into it to see if I can figure out
where expat went wrong.


Here is the output from my simple test app using expat:

defaultHandler: &#039;<?xml version="1.0" ?&#039;
defaultHandler: &#039;&#039;
startElement &#039;document&#039;
.characterData: &#039;&#039;
.characterData: &#039;&#039;
.startElement &#039;test1&#039;
.Attribute: &#039;name&#039; = &#039;if (x<y)&#039;
..characterData: &#039;&#039;
..characterData: &#039;      if (x&#039;
..characterData: &#039;&#039;
..characterData: &#039; y&#039;
..characterData: &#039;&#039;
..characterData: &#039;&#039;
.endElement &#039;test1&#039;
.characterData: &#039;&#039;
endElement &#039;document&#039;


Thanks,
Nicholas



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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2004-03-08 21:36

Message:
Logged In: YES 
user_id=290026

Yes, and that behaviour of the characterData handler
would be the effect of setting a default handler with
XML_SetDefaultHandler instead of 
XML_SetDefaultHandlerExpand.
So, what function did you use to set your default handler?

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-03-08 20:24

Message:
Logged In: NO 

It is the characterData handler that is not properly
processing the 'less than' sequence. 

If you notice, the 'less than' sequence was properly handled
in the element handler.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-02-25 11:32

Message:
Logged In: YES 
user_id=290026

One thing that comes to mind:

There are two ways of setting a default handler.
One of them suppresses reporting of internal entitities.

Please check the docs and compare with your code.

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

Comment By: Nicholas hendricks (nhendricks)
Date: 2004-02-25 11:24

Message:
Logged In: YES 
user_id=977364

Make that a &lt; where the < is.  
I didn't realize sourceforce would parse the comments,
instead of including them as plain text.

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

Comment By: Nicholas hendricks (nhendricks)
Date: 2004-02-25 11:20

Message:
Logged In: YES 
user_id=977364

I am a sourceforce NOOB, so I cant figure out how to attach
files.

The < in the above example should be <



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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-02-18 10:51

Message:
Logged In: YES 
user_id=290026

The way your document appears here is not well-formed, but
maybe the HTML processing expanded some entities.
Please attach the document as a file.

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

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

From noreply at sourceforge.net  Wed Mar 10 15:06:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 10 15:06:24 2004
Subject: [Expat-bugs] [ expat-Bugs-898906 ] Expat fails to correctly parse
	content data
Message-ID: <E1B19y5-0002lS-00@sc8-sf-web1.sourceforge.net>

Bugs item #898906, was opened at 2004-02-17 17:33
Message generated for change (Comment added) made by nhendricks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=898906&group_id=10127

Category: www.libexpat.org
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Expat fails to correctly parse content data

Initial Comment:
In the following XML file:
<?xml version="1.0" ?>
<document>
	<test1 name="if (x<y)" >
	if (x < y)
	</test1>
</document>

the < in the attribute is correctly returned as "<",
however, in the character block, it appears to be 
returned as a NULL.



I will try to look into it to see if I can figure out
where expat went wrong.


Here is the output from my simple test app using expat:

defaultHandler: &#039;<?xml version="1.0" ?&#039;
defaultHandler: &#039;&#039;
startElement &#039;document&#039;
.characterData: &#039;&#039;
.characterData: &#039;&#039;
.startElement &#039;test1&#039;
.Attribute: &#039;name&#039; = &#039;if (x<y)&#039;
..characterData: &#039;&#039;
..characterData: &#039;      if (x&#039;
..characterData: &#039;&#039;
..characterData: &#039; y&#039;
..characterData: &#039;&#039;
..characterData: &#039;&#039;
.endElement &#039;test1&#039;
.characterData: &#039;&#039;
endElement &#039;document&#039;


Thanks,
Nicholas



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

Comment By: Nicholas hendricks (nhendricks)
Date: 2004-03-10 20:06

Message:
Logged In: YES 
user_id=977364

I tried setting the default handler to the Expand default,
but this did not help.

I reviewed the xml spec & according to section 4.4,
character references must be expanded in characater data.
Using a different default handler should not have any affect
on how character references are handled...

I went ahead & trapped this in the debugger. It appears the
problem occurs around line 2334 in xmlparse.c.
Look for case XML_TOK_DATA_CHARS:

In this case stamement, XmlConvert is conditionally called
before the character callback. In my case, XmlConvert does
not get called for the character data.

The reason it works in the attribute case is that XmlConvert
is always called. 

This really looks like a bug in expat, not in my usage of it.

Thanks for looking into it.
Nicholas Hendricks

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-03-09 02:36

Message:
Logged In: YES 
user_id=290026

Yes, and that behaviour of the characterData handler
would be the effect of setting a default handler with
XML_SetDefaultHandler instead of 
XML_SetDefaultHandlerExpand.
So, what function did you use to set your default handler?

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-03-09 01:24

Message:
Logged In: NO 

It is the characterData handler that is not properly
processing the 'less than' sequence. 

If you notice, the 'less than' sequence was properly handled
in the element handler.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-02-25 16:32

Message:
Logged In: YES 
user_id=290026

One thing that comes to mind:

There are two ways of setting a default handler.
One of them suppresses reporting of internal entitities.

Please check the docs and compare with your code.

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

Comment By: Nicholas hendricks (nhendricks)
Date: 2004-02-25 16:24

Message:
Logged In: YES 
user_id=977364

Make that a &lt; where the < is.  
I didn't realize sourceforce would parse the comments,
instead of including them as plain text.

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

Comment By: Nicholas hendricks (nhendricks)
Date: 2004-02-25 16:20

Message:
Logged In: YES 
user_id=977364

I am a sourceforce NOOB, so I cant figure out how to attach
files.

The < in the above example should be <



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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-02-18 15:51

Message:
Logged In: YES 
user_id=290026

The way your document appears here is not well-formed, but
maybe the HTML processing expanded some entities.
Please attach the document as a file.

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

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

From noreply at sourceforge.net  Wed Mar 10 23:13:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 10 23:14:00 2004
Subject: [Expat-bugs] [ expat-Bugs-898906 ] Expat fails to correctly parse
	content data
Message-ID: <E1B1HZy-0007XA-00@sc8-sf-web2.sourceforge.net>

Bugs item #898906, was opened at 2004-02-17 12:33
Message generated for change (Comment added) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=898906&group_id=10127

Category: www.libexpat.org
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Expat fails to correctly parse content data

Initial Comment:
In the following XML file:
<?xml version="1.0" ?>
<document>
	<test1 name="if (x<y)" >
	if (x < y)
	</test1>
</document>

the < in the attribute is correctly returned as "<",
however, in the character block, it appears to be 
returned as a NULL.



I will try to look into it to see if I can figure out
where expat went wrong.


Here is the output from my simple test app using expat:

defaultHandler: &#039;<?xml version="1.0" ?&#039;
defaultHandler: &#039;&#039;
startElement &#039;document&#039;
.characterData: &#039;&#039;
.characterData: &#039;&#039;
.startElement &#039;test1&#039;
.Attribute: &#039;name&#039; = &#039;if (x<y)&#039;
..characterData: &#039;&#039;
..characterData: &#039;      if (x&#039;
..characterData: &#039;&#039;
..characterData: &#039; y&#039;
..characterData: &#039;&#039;
..characterData: &#039;&#039;
.endElement &#039;test1&#039;
.characterData: &#039;&#039;
endElement &#039;document&#039;


Thanks,
Nicholas



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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2004-03-10 23:13

Message:
Logged In: YES 
user_id=290026

Please e-mail me the xml file that causes your problem.
I will have a look at it.

My address: karl@waclawek.net

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

Comment By: Nicholas hendricks (nhendricks)
Date: 2004-03-10 15:06

Message:
Logged In: YES 
user_id=977364

I tried setting the default handler to the Expand default,
but this did not help.

I reviewed the xml spec & according to section 4.4,
character references must be expanded in characater data.
Using a different default handler should not have any affect
on how character references are handled...

I went ahead & trapped this in the debugger. It appears the
problem occurs around line 2334 in xmlparse.c.
Look for case XML_TOK_DATA_CHARS:

In this case stamement, XmlConvert is conditionally called
before the character callback. In my case, XmlConvert does
not get called for the character data.

The reason it works in the attribute case is that XmlConvert
is always called. 

This really looks like a bug in expat, not in my usage of it.

Thanks for looking into it.
Nicholas Hendricks

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-03-08 21:36

Message:
Logged In: YES 
user_id=290026

Yes, and that behaviour of the characterData handler
would be the effect of setting a default handler with
XML_SetDefaultHandler instead of 
XML_SetDefaultHandlerExpand.
So, what function did you use to set your default handler?

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-03-08 20:24

Message:
Logged In: NO 

It is the characterData handler that is not properly
processing the 'less than' sequence. 

If you notice, the 'less than' sequence was properly handled
in the element handler.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-02-25 11:32

Message:
Logged In: YES 
user_id=290026

One thing that comes to mind:

There are two ways of setting a default handler.
One of them suppresses reporting of internal entitities.

Please check the docs and compare with your code.

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

Comment By: Nicholas hendricks (nhendricks)
Date: 2004-02-25 11:24

Message:
Logged In: YES 
user_id=977364

Make that a &lt; where the < is.  
I didn't realize sourceforce would parse the comments,
instead of including them as plain text.

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

Comment By: Nicholas hendricks (nhendricks)
Date: 2004-02-25 11:20

Message:
Logged In: YES 
user_id=977364

I am a sourceforce NOOB, so I cant figure out how to attach
files.

The < in the above example should be <



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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-02-18 10:51

Message:
Logged In: YES 
user_id=290026

The way your document appears here is not well-formed, but
maybe the HTML processing expanded some entities.
Please attach the document as a file.

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

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

From noreply at sourceforge.net  Thu Mar 11 12:03:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 11 12:04:01 2004
Subject: [Expat-bugs] [ expat-Bugs-898906 ] Expat fails to correctly parse
	content data
Message-ID: <E1B1Tb6-0005vj-00@sc8-sf-web1.sourceforge.net>

Bugs item #898906, was opened at 2004-02-17 12:33
Message generated for change (Comment added) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=898906&group_id=10127

Category: www.libexpat.org
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Expat fails to correctly parse content data

Initial Comment:
In the following XML file:
<?xml version="1.0" ?>
<document>
	<test1 name="if (x<y)" >
	if (x < y)
	</test1>
</document>

the < in the attribute is correctly returned as "<",
however, in the character block, it appears to be 
returned as a NULL.



I will try to look into it to see if I can figure out
where expat went wrong.


Here is the output from my simple test app using expat:

defaultHandler: &#039;<?xml version="1.0" ?&#039;
defaultHandler: &#039;&#039;
startElement &#039;document&#039;
.characterData: &#039;&#039;
.characterData: &#039;&#039;
.startElement &#039;test1&#039;
.Attribute: &#039;name&#039; = &#039;if (x<y)&#039;
..characterData: &#039;&#039;
..characterData: &#039;      if (x&#039;
..characterData: &#039;&#039;
..characterData: &#039; y&#039;
..characterData: &#039;&#039;
..characterData: &#039;&#039;
.endElement &#039;test1&#039;
.characterData: &#039;&#039;
endElement &#039;document&#039;


Thanks,
Nicholas



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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2004-03-11 12:03

Message:
Logged In: YES 
user_id=290026

I just checked your code reference, and in my version of 
xmlparse.c, XML_TOK_DATA_CHARS is nowhere near line 
2334. I also could not find a condition for calling XmlConvert().

So, which version of Expat are you using?


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-03-10 23:13

Message:
Logged In: YES 
user_id=290026

Please e-mail me the xml file that causes your problem.
I will have a look at it.

My address: karl@waclawek.net

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

Comment By: Nicholas hendricks (nhendricks)
Date: 2004-03-10 15:06

Message:
Logged In: YES 
user_id=977364

I tried setting the default handler to the Expand default,
but this did not help.

I reviewed the xml spec & according to section 4.4,
character references must be expanded in characater data.
Using a different default handler should not have any affect
on how character references are handled...

I went ahead & trapped this in the debugger. It appears the
problem occurs around line 2334 in xmlparse.c.
Look for case XML_TOK_DATA_CHARS:

In this case stamement, XmlConvert is conditionally called
before the character callback. In my case, XmlConvert does
not get called for the character data.

The reason it works in the attribute case is that XmlConvert
is always called. 

This really looks like a bug in expat, not in my usage of it.

Thanks for looking into it.
Nicholas Hendricks

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-03-08 21:36

Message:
Logged In: YES 
user_id=290026

Yes, and that behaviour of the characterData handler
would be the effect of setting a default handler with
XML_SetDefaultHandler instead of 
XML_SetDefaultHandlerExpand.
So, what function did you use to set your default handler?

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-03-08 20:24

Message:
Logged In: NO 

It is the characterData handler that is not properly
processing the 'less than' sequence. 

If you notice, the 'less than' sequence was properly handled
in the element handler.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-02-25 11:32

Message:
Logged In: YES 
user_id=290026

One thing that comes to mind:

There are two ways of setting a default handler.
One of them suppresses reporting of internal entitities.

Please check the docs and compare with your code.

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

Comment By: Nicholas hendricks (nhendricks)
Date: 2004-02-25 11:24

Message:
Logged In: YES 
user_id=977364

Make that a &lt; where the < is.  
I didn't realize sourceforce would parse the comments,
instead of including them as plain text.

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

Comment By: Nicholas hendricks (nhendricks)
Date: 2004-02-25 11:20

Message:
Logged In: YES 
user_id=977364

I am a sourceforce NOOB, so I cant figure out how to attach
files.

The < in the above example should be <



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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-02-18 10:51

Message:
Logged In: YES 
user_id=290026

The way your document appears here is not well-formed, but
maybe the HTML processing expanded some entities.
Please attach the document as a file.

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

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

From noreply at sourceforge.net  Sun Mar 14 19:25:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 14 21:37:10 2004
Subject: [Expat-bugs] [ expat-Bugs-898906 ] Expat fails to correctly parse
	content data
Message-ID: <E1B2fvD-0000Ec-00@sc8-sf-web4.sourceforge.net>

Bugs item #898906, was opened at 2004-02-17 12:33
Message generated for change (Comment added) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=898906&group_id=10127

>Category: None
>Group: Not a Bug
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Expat fails to correctly parse content data

Initial Comment:
In the following XML file:
<?xml version="1.0" ?>
<document>
	<test1 name="if (x<y)" >
	if (x < y)
	</test1>
</document>

the < in the attribute is correctly returned as "<",
however, in the character block, it appears to be 
returned as a NULL.



I will try to look into it to see if I can figure out
where expat went wrong.


Here is the output from my simple test app using expat:

defaultHandler: &#039;<?xml version="1.0" ?&#039;
defaultHandler: &#039;&#039;
startElement &#039;document&#039;
.characterData: &#039;&#039;
.characterData: &#039;&#039;
.startElement &#039;test1&#039;
.Attribute: &#039;name&#039; = &#039;if (x<y)&#039;
..characterData: &#039;&#039;
..characterData: &#039;      if (x&#039;
..characterData: &#039;&#039;
..characterData: &#039; y&#039;
..characterData: &#039;&#039;
..characterData: &#039;&#039;
.endElement &#039;test1&#039;
.characterData: &#039;&#039;
endElement &#039;document&#039;


Thanks,
Nicholas



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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2004-03-14 19:25

Message:
Logged In: YES 
user_id=290026

Examined code provided by submitter.
Seems there was an assumption that character data are
reported as null-terminated string, which it is not. 
Changing the code accordingly solved problem.

Closed - not a bug.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-03-11 12:03

Message:
Logged In: YES 
user_id=290026

I just checked your code reference, and in my version of 
xmlparse.c, XML_TOK_DATA_CHARS is nowhere near line 
2334. I also could not find a condition for calling XmlConvert().

So, which version of Expat are you using?


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-03-10 23:13

Message:
Logged In: YES 
user_id=290026

Please e-mail me the xml file that causes your problem.
I will have a look at it.

My address: karl@waclawek.net

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

Comment By: Nicholas hendricks (nhendricks)
Date: 2004-03-10 15:06

Message:
Logged In: YES 
user_id=977364

I tried setting the default handler to the Expand default,
but this did not help.

I reviewed the xml spec & according to section 4.4,
character references must be expanded in characater data.
Using a different default handler should not have any affect
on how character references are handled...

I went ahead & trapped this in the debugger. It appears the
problem occurs around line 2334 in xmlparse.c.
Look for case XML_TOK_DATA_CHARS:

In this case stamement, XmlConvert is conditionally called
before the character callback. In my case, XmlConvert does
not get called for the character data.

The reason it works in the attribute case is that XmlConvert
is always called. 

This really looks like a bug in expat, not in my usage of it.

Thanks for looking into it.
Nicholas Hendricks

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-03-08 21:36

Message:
Logged In: YES 
user_id=290026

Yes, and that behaviour of the characterData handler
would be the effect of setting a default handler with
XML_SetDefaultHandler instead of 
XML_SetDefaultHandlerExpand.
So, what function did you use to set your default handler?

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-03-08 20:24

Message:
Logged In: NO 

It is the characterData handler that is not properly
processing the 'less than' sequence. 

If you notice, the 'less than' sequence was properly handled
in the element handler.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-02-25 11:32

Message:
Logged In: YES 
user_id=290026

One thing that comes to mind:

There are two ways of setting a default handler.
One of them suppresses reporting of internal entitities.

Please check the docs and compare with your code.

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

Comment By: Nicholas hendricks (nhendricks)
Date: 2004-02-25 11:24

Message:
Logged In: YES 
user_id=977364

Make that a &lt; where the < is.  
I didn't realize sourceforce would parse the comments,
instead of including them as plain text.

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

Comment By: Nicholas hendricks (nhendricks)
Date: 2004-02-25 11:20

Message:
Logged In: YES 
user_id=977364

I am a sourceforce NOOB, so I cant figure out how to attach
files.

The < in the above example should be <



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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-02-18 10:51

Message:
Logged In: YES 
user_id=290026

The way your document appears here is not well-formed, but
maybe the HTML processing expanded some entities.
Please attach the document as a file.

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

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

From noreply at sourceforge.net  Sun Mar 14 19:39:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 14 21:37:21 2004
Subject: [Expat-bugs] [ expat-Bugs-916228 ] Crash when XML_DTD not defined
Message-ID: <E1B2g8i-00011C-00@sc8-sf-web4.sourceforge.net>

Bugs item #916228, was opened at 2004-03-14 19:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=916228&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Karl Waclawek (kwaclaw)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Crash when XML_DTD not defined

Initial Comment:
Reported by Nicholas Hendricks:

When XML_DTD is not defined, but an internal general
entity is declared, Expat crashes in storeEntityValue,
since the string pool "entityValuePool" is not initialized
in this case.

The solution is to remove the compile condition for
initializing and finalizing entityValuePool.

The attached file test1.xml causes the crash when
using an instance of Expat compiled with XML_DTD 
undefined.

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

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

From noreply at sourceforge.net  Sun Mar 14 19:45:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 14 21:37:24 2004
Subject: [Expat-bugs] [ expat-Bugs-916228 ] Crash when XML_DTD not defined
Message-ID: <E1B2gEh-0001L0-00@sc8-sf-web4.sourceforge.net>

Bugs item #916228, was opened at 2004-03-14 19:39
Message generated for change (Comment added) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=916228&group_id=10127

Category: None
>Group: Test Required
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Karl Waclawek (kwaclaw)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Crash when XML_DTD not defined

Initial Comment:
Reported by Nicholas Hendricks:

When XML_DTD is not defined, but an internal general
entity is declared, Expat crashes in storeEntityValue,
since the string pool "entityValuePool" is not initialized
in this case.

The solution is to remove the compile condition for
initializing and finalizing entityValuePool.

The attached file test1.xml causes the crash when
using an instance of Expat compiled with XML_DTD 
undefined.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2004-03-14 19:45

Message:
Logged In: YES 
user_id=290026

Fixed in revision 1.124 of xmlparse.c - see attached file 
xmlparse.diff.

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

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

From noreply at sourceforge.net  Sun Mar 14 19:49:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 14 21:37:25 2004
Subject: [Expat-bugs] [ expat-Bugs-916232 ] Docs for XML_DTD seem wrong
Message-ID: <E1B2gIb-0005mn-00@sc8-sf-web2.sourceforge.net>

Bugs item #916232, was opened at 2004-03-14 19:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=916232&group_id=10127

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Karl Waclawek (kwaclaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Docs for XML_DTD seem wrong

Initial Comment:
As far as I can tell, when XML_DTD is not defined the 
only functionality not present is the ability to process 
external parameter entities and (not sure) conditional 
sections.

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

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

From noreply at sourceforge.net  Mon Mar 15 11:14:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 15 12:16:03 2004
Subject: [Expat-bugs] [ expat-Bugs-916718 ] CDATA Sections is not parsed
	Properly
Message-ID: <E1B2uj9-0004nf-00@sc8-sf-web4.sourceforge.net>

Bugs item #916718, was opened at 2004-03-15 08:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=916718&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: CDATA Sections is not parsed Properly

Initial Comment:
When Expat encounters CDATA, it should parse it as a 
CDATA, but it&#039;s parsing normally

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

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

From noreply at sourceforge.net  Mon Mar 15 13:00:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 15 13:00:28 2004
Subject: [Expat-bugs] [ expat-Bugs-916718 ] CDATA Sections is not parsed
	Properly
Message-ID: <E1B2wNx-0007cQ-00@sc8-sf-web4.sourceforge.net>

Bugs item #916718, was opened at 2004-03-15 11:14
Message generated for change (Comment added) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=916718&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Karl Waclawek (kwaclaw)
Summary: CDATA Sections is not parsed Properly

Initial Comment:
When Expat encounters CDATA, it should parse it as a 
CDATA, but it&#039;s parsing normally

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2004-03-15 13:00

Message:
Logged In: YES 
user_id=290026

CDATA sections work fine for me.
I have no idea what you mean - can you be more specific?

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

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

From noreply at sourceforge.net  Tue Mar 16 10:08:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 16 13:02:56 2004
Subject: [Expat-bugs] [ expat-Bugs-221310 ] File missing during install of
	Expat
Message-ID: <E1B3GBO-0001RF-00@sc8-sf-web1.sourceforge.net>

Bugs item #221310, was opened at 2000-11-03 12:15
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=221310&group_id=10127

Category: None
Group: None
Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: Orbhost Sysadmin (orbhostadmin)
Assigned to: Clark Cooper (coopercc)
Summary: File missing during install of Expat

Initial Comment:
Platform is Alpha Tru64 V5.1

CC="cc" MAKE="gmake" ./configure

creating cache ./config.cache
checking host system type... alphaev56-dec-osf5.1
checking build system type... alphaev56-dec-osf5.1
checking for ranlib... ranlib
checking for gcc... cc
checking whether the C compiler (cc  ) works... yes
checking whether the C compiler (cc  ) is a cross-compiler... no
checking whether we are using GNU C... no
checking whether cc accepts -g... yes
checking for non-GNU ld... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking for BSD-compatible nm... /usr/local/bin/nm -B
checking whether ln -s works... yes
updating cache ./config.cache
loading cache ./config.cache within ltconfig
checking whether we are using GNU C... no
checking for object suffix... o
checking for executable suffix... no
checking for cc option to produce PIC... none
checking if cc supports -c -o file.o... yes
checking if cc supports -c -o file.lo... yes
checking if cc static flag -non_shared works... -non_shared
checking if the linker (/usr/bin/ld) is GNU ld... no
checking whether the linker (/usr/bin/ld) supports shared libraries... yes
checking command to parse /usr/local/bin/nm -B output... ok
checking how to hardcode library paths into programs... immediate
checking for /usr/bin/ld option to reload object files... -r
checking dynamic linker characteristics... osf5.1 ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for objdir... .libs
creating libtool
updating cache ./config.cache
loading cache ./config.cache
checking for gcc... (cached) cc
checking whether the C compiler (cc -g ) works... yes
checking whether the C compiler (cc -g ) is a cross-compiler... no
checking whether we are using GNU C... (cached) no
checking whether cc accepts -g... (cached) yes
checking for a BSD compatible install... /usr/local/bin/install -c
checking how to run the C preprocessor... cc -E
checking for ANSI C header files... yes
checking for fcntl.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking for working const... yes
checking for off_t... yes
checking for size_t... yes
checking for 8-bit clean memcmp... yes
checking for unistd.h... (cached) yes
checking for getpagesize... yes
checking for working mmap... yes
checking for memmove... yes
checking for bcopy... yes
updating cache ./config.cache
creating ./config.status
creating Makefile
creating lib/Makefile
creating xmlwf/Makefile
creating examples/Makefile
creating config.h

gmake

cd lib; gmake
gmake[1]: Entering directory `/usr/users/dg/work/expat-1.95.1/lib&#039;
/bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=expat_1.95.1 -I. -I..  -g -c xmlparse.c
mkdir .libs
cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.1\ -I. -I.. -g -Wp,-MD,.deps/xmlparse.pp -c xmlparse.c  -DPIC -o .lib
s/xmlparse.lo
cc: Severe: No such file or directory
... file is &#039;.deps/xmlparse.pp&#039;
gmake[1]: *** [xmlparse.lo] Error 1
gmake[1]: Leaving directory `/usr/users/dg/work/expat-1.95.1/lib&#039;
gmake: *** [lib] Error 2

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-03-16 07:08

Message:
Logged In: NO 

Clark,

It may indeed be a problem as you indicated in that
scenario, however the problem remains:

Checking if your kit is complete...
Looks good
Writing Makefile for XML::Parser::Expat
Writing Makefile for XML::Parser
cp Parser/Encodings/x-sjis-cp932.enc
blib/lib/XML/Parser/Encodings/x-sjis-cp932.enc
cp Parser/Encodings/iso-8859-7.enc
blib/lib/XML/Parser/Encodings/iso-8859-7.enc
cp Parser/Style/Tree.pm blib/lib/XML/Parser/Style/Tree.pm
cp Parser/Encodings/iso-8859-9.enc
blib/lib/XML/Parser/Encodings/iso-8859-9.enc
cp Parser/Encodings/x-euc-jp-unicode.enc
blib/lib/XML/Parser/Encodings/x-euc-jp-unicode.enc
cp Parser/Encodings/README blib/lib/XML/Parser/Encodings/README
cp Parser/Encodings/euc-kr.enc
blib/lib/XML/Parser/Encodings/euc-kr.enc
cp Parser/Encodings/windows-1250.enc
blib/lib/XML/Parser/Encodings/windows-1250.enc
cp Parser/Encodings/windows-1252.enc
blib/lib/XML/Parser/Encodings/windows-1252.enc
cp Parser/Encodings/big5.enc
blib/lib/XML/Parser/Encodings/big5.enc
cp Parser/Encodings/iso-8859-3.enc
blib/lib/XML/Parser/Encodings/iso-8859-3.enc
cp Parser/Encodings/Japanese_Encodings.msg
blib/lib/XML/Parser/Encodings/Japanese_Encodings.msg
cp Parser/Style/Subs.pm blib/lib/XML/Parser/Style/Subs.pm
cp Parser/Encodings/x-euc-jp-jisx0221.enc
blib/lib/XML/Parser/Encodings/x-euc-jp-jisx0221.enc
cp Parser/Encodings/iso-8859-8.enc
blib/lib/XML/Parser/Encodings/iso-8859-8.enc
cp Parser/Encodings/iso-8859-4.enc
blib/lib/XML/Parser/Encodings/iso-8859-4.enc
cp Parser/Encodings/iso-8859-2.enc
blib/lib/XML/Parser/Encodings/iso-8859-2.enc
cp Parser/Encodings/x-sjis-jdk117.enc
blib/lib/XML/Parser/Encodings/x-sjis-jdk117.enc
cp Parser/LWPExternEnt.pl blib/lib/XML/Parser/LWPExternEnt.pl
cp Parser/Encodings/x-sjis-unicode.enc
blib/lib/XML/Parser/Encodings/x-sjis-unicode.enc
cp Parser/Style/Objects.pm blib/lib/XML/Parser/Style/Objects.pm
cp Parser/Style/Debug.pm blib/lib/XML/Parser/Style/Debug.pm
cp Parser.pm blib/lib/XML/Parser.pm
cp Parser/Encodings/x-sjis-jisx0221.enc
blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc
cp Parser/Style/Stream.pm blib/lib/XML/Parser/Style/Stream.pm
cp Parser/Encodings/iso-8859-5.enc
blib/lib/XML/Parser/Encodings/iso-8859-5.enc
make[1]: Entering directory
`/root/.cpan/build/XML-Parser-2.34/Expat'
cp Expat.pm ../blib/lib/XML/Parser/Expat.pm
/usr/bin/perl /usr/lib/perl5/5.8.0/ExtUtils/xsubpp
-noprototypes -typemap /usr/lib/perl5/5.8.0/ExtUtils/typemap
-typemap typemap  Expat.xs > Expat.xsc && mv Expat.xsc Expat.c
gcc -c   -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/include/gdbm -O2 -march=i386 -mcpu=i686  
-DVERSION=\2.34\ -DXS_VERSION=\2.34\ -fpic
"-I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE"   Expat.c
Expat.xs:12:19: expat.h: No such file or directory

This is from RedHat 8.  A simple "find" under the directory
/root/.cpan/sources/authors/id/M/MS/MSERGEANT/XML-Parser-2.34
shows no expat.h file anywhere.


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

Comment By: Clark Cooper (coopercc)
Date: 2000-12-21 07:37

Message:
There's no file missing. Your cc doesn't recognize the flags for checking header dependencies. If it recognized

 -Wp,-MD,.deps/xmlparse.pp

then your compiler would generate the file. This is a configuration and or Makefile problem.

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

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

From noreply at sourceforge.net  Thu Mar 18 08:20:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 18 08:20:46 2004
Subject: [Expat-bugs] [ expat-Bugs-918730 ] namespace uri's arent checked
	for an ending hash
Message-ID: <E1B3xRx-0006eZ-00@sc8-sf-web4.sourceforge.net>

Bugs item #918730, was opened at 2004-03-18 14:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=918730&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jasper (jaspervdg)
Assigned to: Nobody/Anonymous (nobody)
Summary: namespace uri's arent checked for an ending hash

Initial Comment:
With a document like this (made much shorter):
<rdf:RDF xmlns:rdf =
"http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc  = "http://purl.org/dc/elements/1.1/"
         xmlns:mm  = "http://musicbrainz.org/mm/mm-2.1#">
  <mm:Artist
rdf:about="http://musicbrainz.org/artist/88a6037e-87ba-492a-a54c-c927aa620cb8">
    <dc:title>Earth Crisis</dc:title>
  </mm:Artist>
</rdf:RDF>
The element types are resolved as follows (namespace
separator is set to a hash):
  rdf:RDF ->
http://www.w3.org/1999/02/22-rdf-syntax-ns##RDF
  mm:Artist -> http://musicbrainz.org/mm/mm-2.1##Artist
  dc:title -> http://purl.org/dc/elements/1.1/#title
As far as I know that&#039;s not how it should be (having
two hashes as separator in the first two cases). For my
purpose I fixed it by modifying addBinding (in
xmlparse.c) to check whether the namespace URI already
ends in a hash.
I am using version 1.95.7.


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

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

From noreply at sourceforge.net  Thu Mar 18 09:17:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 18 09:17:24 2004
Subject: [Expat-bugs] [ expat-Bugs-918730 ] namespace uri's arent checked
	for an ending hash
Message-ID: <E1B3yKh-0005VI-00@sc8-sf-web3.sourceforge.net>

Bugs item #918730, was opened at 2004-03-18 08:20
Message generated for change (Comment added) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=918730&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jasper (jaspervdg)
Assigned to: Nobody/Anonymous (nobody)
Summary: namespace uri's arent checked for an ending hash

Initial Comment:
With a document like this (made much shorter):
<rdf:RDF xmlns:rdf =
"http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc  = "http://purl.org/dc/elements/1.1/"
         xmlns:mm  = "http://musicbrainz.org/mm/mm-2.1#">
  <mm:Artist
rdf:about="http://musicbrainz.org/artist/88a6037e-87ba-492a-a54c-c927aa620cb8">
    <dc:title>Earth Crisis</dc:title>
  </mm:Artist>
</rdf:RDF>
The element types are resolved as follows (namespace
separator is set to a hash):
  rdf:RDF ->
http://www.w3.org/1999/02/22-rdf-syntax-ns##RDF
  mm:Artist -> http://musicbrainz.org/mm/mm-2.1##Artist
  dc:title -> http://purl.org/dc/elements/1.1/#title
As far as I know that&#039;s not how it should be (having
two hashes as separator in the first two cases). For my
purpose I fixed it by modifying addBinding (in
xmlparse.c) to check whether the namespace URI already
ends in a hash.
I am using version 1.95.7.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2004-03-18 09:17

Message:
Logged In: YES 
user_id=290026

AFAIK, Expat does not check URIs for conformance at all.
Maybe it should, but this is not implemented. In the case
above I think the XML Namespaces spec allows hash marks,
as they are legal in an URI reference.

So, if you pick a namespace separator that can occur in your
URIs then this is your problem, as the above looks like Expat 
works as designed. 

I suggest you try a character as namespace separator that
is not a legal XML character. That should always work.

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

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

From noreply at sourceforge.net  Sat Mar 20 18:35:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 18:35:40 2004
Subject: [Expat-bugs] [ expat-Bugs-920274 ] xml: namespace not closed after
	entity
Message-ID: <E1B4q06-0007Wn-00@sc8-sf-web4.sourceforge.net>

Bugs item #920274, was opened at 2004-03-20 15:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=920274&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml: namespace not closed after entity

Initial Comment:
When an external entity is parsed, StartNamespaceDecl is
called for xml http://www.w3.org/1998/namespace (from
setContext). On exit, EndNamespaceDecl is not called, and
the calls become unbalanced.

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

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

From noreply at sourceforge.net  Sat Mar 20 21:52:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 21:52:37 2004
Subject: [Expat-bugs] [ expat-Bugs-920274 ] xml: namespace not closed after
	entity
Message-ID: <E1B4t4i-0007oN-00@sc8-sf-web3.sourceforge.net>

Bugs item #920274, was opened at 2004-03-20 18:35
Message generated for change (Comment added) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=920274&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml: namespace not closed after entity

Initial Comment:
When an external entity is parsed, StartNamespaceDecl is
called for xml http://www.w3.org/1998/namespace (from
setContext). On exit, EndNamespaceDecl is not called, and
the calls become unbalanced.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2004-03-20 21:52

Message:
Logged In: YES 
user_id=290026

I looked at the code, and I am wondering why 
startNamespaceDecl() is called at all. 
Why should Expat call it when starting to parse an external
entity? Am I overlooking something?
At the moment it appears to me that this call-back is
an undesirable side-effect of a child parser inheriting
namespace scopes.


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

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

From noreply at sourceforge.net  Mon Mar 22 22:58:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 22 22:58:11 2004
Subject: [Expat-bugs] [ expat-Bugs-920274 ] xml: namespace not closed after
	entity
Message-ID: <E1B5d3H-0008BR-00@sc8-sf-web2.sourceforge.net>

Bugs item #920274, was opened at 2004-03-20 18:35
Message generated for change (Comment added) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=920274&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Karl Waclawek (kwaclaw)
Summary: xml: namespace not closed after entity

Initial Comment:
When an external entity is parsed, StartNamespaceDecl is
called for xml http://www.w3.org/1998/namespace (from
setContext). On exit, EndNamespaceDecl is not called, and
the calls become unbalanced.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2004-03-22 22:58

Message:
Logged In: YES 
user_id=290026

Assigned to me - would like to have this resolved
before releasing 1.95.8.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-03-20 21:52

Message:
Logged In: YES 
user_id=290026

I looked at the code, and I am wondering why 
startNamespaceDecl() is called at all. 
Why should Expat call it when starting to parse an external
entity? Am I overlooking something?
At the moment it appears to me that this call-back is
an undesirable side-effect of a child parser inheriting
namespace scopes.


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

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

From noreply at sourceforge.net  Fri Mar 26 09:33:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 26 09:33:23 2004
Subject: [Expat-bugs] [ expat-Bugs-923913 ] Calling convention problems
Message-ID: <E1B6sOd-0003Lf-00@sc8-sf-web2.sourceforge.net>

Bugs item #923913, was opened at 2004-03-26 09:33
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=923913&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Karl Waclawek (kwaclaw)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Calling convention problems

Initial Comment:
Two problems I found in Windows, when trying to define 
XMLCALL as __stdcall:

1) 
In Expat.h, this struct is defined:

typedef struct {
  int map[256];
  void *data;
  int (XMLCALL *convert)(void *data, const char *s);
  void (XMLCALL *release)(void *data);
} XML_Encoding;

in xmltok.h, this function pointer is defined:

  typedef int (*CONVERTER) (void *userData, const char 
*p);

which maps to the third struct member.
So, if the calling convention in XMLCALL is different from
the default, we have a type mismatch.

2) 
In expat.h, we define the calling convention for
the memory handling function pointers like this:

typedef struct {
  void *(XMLCALL *malloc_fcn)(size_t size);
  void *(XMLCALL *realloc_fcn)(void *ptr, size_t size);
  void (XMLCALL *free_fcn)(void *ptr);
} XML_Memory_Handling_Suite;

However, when none are provided by the application, 
we are assigning the standard memory allocation 
functions to it. Which creates a problems, as these 
always have the same calling convention.

Suggested solutions:
1) Remove external API definitions from expat.h and
move them into a file external.h, that can be included
by other files that also have a dependency on the 
external API.

2) Remove XMLCALL from the function pointer
definitions in the memory handling struct.


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

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

From noreply at sourceforge.net  Fri Mar 26 09:36:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 26 11:03:16 2004
Subject: [Expat-bugs] [ expat-Bugs-923913 ] Calling convention problems
Message-ID: <E1B6sRu-0003fG-00@sc8-sf-web2.sourceforge.net>

Bugs item #923913, was opened at 2004-03-26 09:33
Message generated for change (Comment added) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=923913&group_id=10127

Category: None
>Group: Test Required
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Karl Waclawek (kwaclaw)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Calling convention problems

Initial Comment:
Two problems I found in Windows, when trying to define 
XMLCALL as __stdcall:

1) 
In Expat.h, this struct is defined:

typedef struct {
  int map[256];
  void *data;
  int (XMLCALL *convert)(void *data, const char *s);
  void (XMLCALL *release)(void *data);
} XML_Encoding;

in xmltok.h, this function pointer is defined:

  typedef int (*CONVERTER) (void *userData, const char 
*p);

which maps to the third struct member.
So, if the calling convention in XMLCALL is different from
the default, we have a type mismatch.

2) 
In expat.h, we define the calling convention for
the memory handling function pointers like this:

typedef struct {
  void *(XMLCALL *malloc_fcn)(size_t size);
  void *(XMLCALL *realloc_fcn)(void *ptr, size_t size);
  void (XMLCALL *free_fcn)(void *ptr);
} XML_Memory_Handling_Suite;

However, when none are provided by the application, 
we are assigning the standard memory allocation 
functions to it. Which creates a problems, as these 
always have the same calling convention.

Suggested solutions:
1) Remove external API definitions from expat.h and
move them into a file external.h, that can be included
by other files that also have a dependency on the 
external API.

2) Remove XMLCALL from the function pointer
definitions in the memory handling struct.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2004-03-26 09:36

Message:
Logged In: YES 
user_id=290026

Committed a fix for this:

Checking in expat.dsp;
/cvsroot/expat/expat/lib/expat.dsp,v  <--  expat.dsp
new revision: 1.11; previous revision: 1.10
done
Checking in expat.h;
/cvsroot/expat/expat/lib/expat.h,v  <--  expat.h
new revision: 1.66; previous revision: 1.65
done
Checking in expat_static.dsp;
/cvsroot/expat/expat/lib/expat_static.dsp,v  <--  
expat_static.dsp
new revision: 1.3; previous revision: 1.2
done
Checking in expatw.dsp;
/cvsroot/expat/expat/lib/expatw.dsp,v  <--  expatw.dsp
new revision: 1.4; previous revision: 1.3
done
Checking in expatw_static.dsp;
/cvsroot/expat/expat/lib/expatw_static.dsp,v  <--  
expatw_static.dsp
new revision: 1.3; previous revision: 1.2
done
RCS file: /cvsroot/expat/expat/lib/external.h,v
done
Checking in external.h;
/cvsroot/expat/expat/lib/external.h,v  <--  external.h
initial revision: 1.1
done
Checking in xmlparse.c;
/cvsroot/expat/expat/lib/xmlparse.c,v  <--  xmlparse.c
new revision: 1.130; previous revision: 1.129
done
Checking in xmlrole.c;
/cvsroot/expat/expat/lib/xmlrole.c,v  <--  xmlrole.c
new revision: 1.17; previous revision: 1.16
done
Checking in xmltok.c;
/cvsroot/expat/expat/lib/xmltok.c,v  <--  xmltok.c
new revision: 1.30; previous revision: 1.29
done
Checking in xmltok.h;
/cvsroot/expat/expat/lib/xmltok.h,v  <--  xmltok.h
new revision: 1.10; previous revision: 1.9
done


Assigned to Fred, for testing on Linux.

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

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

From noreply at sourceforge.net  Wed Mar 31 14:12:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 14:12:16 2004
Subject: [Expat-bugs] [ expat-Bugs-926893 ] AMD64 - lib/expat.h: warning:
	`cdecl' attribute ignored
Message-ID: <E1B8l8E-00025w-00@sc8-sf-web2.sourceforge.net>

Bugs item #926893, was opened at 2004-03-31 11:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=926893&group_id=10127

Category: Build control
Group: Platform Specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: AMD64 - lib/expat.h: warning: `cdecl' attribute ignored

Initial Comment:
AMD 64 Opteron (Mandrake 9.2)
Expat 1.95.7

when doing a simple ./configure and make, get about 100
of these messages:

/bin/sh ./libtool --silent --mode=compile gcc -g -O2
-Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H
  -I./lib -I. -o lib/xmlp
arse.lo -c lib/xmlparse.c
In file included from lib/xmlparse.c:20:
lib/expat.h:216: warning: `cdecl&#039; attribute ignored
lib/expat.h:220: warning: `cdecl&#039; attribute ignored
lib/expat.h:236: warning: `cdecl&#039; attribute ignored
...
lib/xmlparse.c:663: warning: `cdecl&#039; attribute ignored
lib/xmlparse.c:669: warning: `cdecl&#039; attribute ignored
lib/xmlparse.c:686: warning: `cdecl&#039; attribute ignored

and
In file included from xmlwf/xmlwf.c:10:
lib/expat.h:216: warning: `cdecl&#039; attribute ignored
...
xmlwf/xmlwf.c:25: warning: `cdecl&#039; attribute ignored
...

and
In file included from xmlwf/xmlfile.c:17:
lib/expat.h:216: warning: `cdecl&#039; attribute ignored
...


This does not happen in 1.95.6
asloan@antarctica.net

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

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

From noreply at sourceforge.net  Wed Mar 31 14:27:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 14:27:45 2004
Subject: [Expat-bugs] [ expat-Bugs-926893 ] AMD64 - lib/expat.h: warning:
	`cdecl' attribute ignored
Message-ID: <E1B8lNE-0006Sb-00@sc8-sf-web1.sourceforge.net>

Bugs item #926893, was opened at 2004-03-31 14:12
Message generated for change (Comment added) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=926893&group_id=10127

Category: Build control
Group: Platform Specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: AMD64 - lib/expat.h: warning: `cdecl' attribute ignored

Initial Comment:
AMD 64 Opteron (Mandrake 9.2)
Expat 1.95.7

when doing a simple ./configure and make, get about 100
of these messages:

/bin/sh ./libtool --silent --mode=compile gcc -g -O2
-Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H
  -I./lib -I. -o lib/xmlp
arse.lo -c lib/xmlparse.c
In file included from lib/xmlparse.c:20:
lib/expat.h:216: warning: `cdecl&#039; attribute ignored
lib/expat.h:220: warning: `cdecl&#039; attribute ignored
lib/expat.h:236: warning: `cdecl&#039; attribute ignored
...
lib/xmlparse.c:663: warning: `cdecl&#039; attribute ignored
lib/xmlparse.c:669: warning: `cdecl&#039; attribute ignored
lib/xmlparse.c:686: warning: `cdecl&#039; attribute ignored

and
In file included from xmlwf/xmlwf.c:10:
lib/expat.h:216: warning: `cdecl&#039; attribute ignored
...
xmlwf/xmlwf.c:25: warning: `cdecl&#039; attribute ignored
...

and
In file included from xmlwf/xmlfile.c:17:
lib/expat.h:216: warning: `cdecl&#039; attribute ignored
...


This does not happen in 1.95.6
asloan@antarctica.net

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2004-03-31 14:27

Message:
Logged In: YES 
user_id=290026

Please try with the current CVS version.
It might be fixed there.

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

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

From noreply at sourceforge.net  Wed Mar 31 15:25:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 15:26:28 2004
Subject: [Expat-bugs] [ expat-Bugs-926945 ] AMD64 - lib/expat.h: warning:
	`cdecl' attribute ignored
Message-ID: <E1B8mHP-0001Ce-00@sc8-sf-web3.sourceforge.net>

Bugs item #926945, was opened at 2004-03-31 12:25
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=926945&group_id=10127

Category: Build control
Group: Platform Specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: AMD64 - lib/expat.h: warning: `cdecl' attribute ignored

Initial Comment:
AMD 64 Opteron (Mandrake 9.2)
Expat 1.95.7

when doing a simple ./configure and make, get about 100
of these messages:

/bin/sh ./libtool --silent --mode=compile gcc -g -O2
-Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H
  -I./lib -I. -o lib/xmlp
arse.lo -c lib/xmlparse.c
In file included from lib/xmlparse.c:20:
lib/expat.h:216: warning: `cdecl&#039; attribute ignored
lib/expat.h:220: warning: `cdecl&#039; attribute ignored
lib/expat.h:236: warning: `cdecl&#039; attribute ignored
...
lib/xmlparse.c:663: warning: `cdecl&#039; attribute ignored
lib/xmlparse.c:669: warning: `cdecl&#039; attribute ignored
lib/xmlparse.c:686: warning: `cdecl&#039; attribute ignored

and
In file included from xmlwf/xmlwf.c:10:
lib/expat.h:216: warning: `cdecl&#039; attribute ignored
...
xmlwf/xmlwf.c:25: warning: `cdecl&#039; attribute ignored
...

and
In file included from xmlwf/xmlfile.c:17:
lib/expat.h:216: warning: `cdecl&#039; attribute ignored
...


This does not happen in 1.95.6
asloan@antarctica.net

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

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