From noreply at sourceforge.net  Wed Aug  4 17:52:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug  4 17:52:06 2004
Subject: [Expat-bugs] [ expat-Bugs-972802 ] Xml document which begin with an
	empty line
Message-ID: <E1BsO3d-0005Yz-00@sc8-sf-web3.sourceforge.net>

Bugs item #972802, was opened at 2004-06-14 16:51
Message generated for change (Comment added) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=972802&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 document which begin with an empty line

Initial Comment:
In a xml document which begins with an empty line, for
example:
"""Start here"""

<?xml version="1.0" ?>
<bugged></bugged>
"""End here"""

Expat give this parse error: 
XML Parsing Error: xml processing instruction not at
start of external entity.
I discoverd this bug when I tried to pass an xhtml
document to firefox via ASP.NET with the
"application/xhtml+xml" content-type.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2004-08-04 11:52

Message:
Logged In: YES 
user_id=290026

Let's leave this as an improvement for release 2.0.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-23 00:06

Message:
Logged In: YES 
user_id=3066

Karl, did you want to do anything with this for 1.95.8?

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-06-15 08:55

Message:
Logged In: YES 
user_id=290026

>From the XML spec:
[1]    document    ::=    prolog element Misc*
[22]    prolog    ::=    XMLDecl? Misc* (doctypedecl Misc*)? 
[23]    XMLDecl    ::=    '<?xml' VersionInfo EncodingDecl? 
SDDecl? S? '?>' 

Which means that it is an error if an XML document starts
with an empty line. So Expat is OK. However, Expat's error
message could be improved to say: "XML/Text declaration
not at start of external entity".

So maybe we should change the message.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=972802&group_id=10127
From noreply at sourceforge.net  Fri Aug  6 03:24:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug  6 03:24:34 2004
Subject: [Expat-bugs] [ expat-Bugs-1004302 ] CharcterData splitted in the
	middle when isFinal=0
Message-ID: <E1BstTC-0001Ub-00@sc8-sf-web4.sourceforge.net>

Bugs item #1004302, was opened at 2004-08-06 03:24
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=1004302&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Quinson (mquinson)
Assigned to: Nobody/Anonymous (nobody)
Summary: CharcterData splitted in the middle when isFinal=0

Initial Comment:
Hello,

I'm trying to use expat on very big document (about
50Mb), so the first bad news is that XML_Parse takes
the size of the buffer as a regular int instead of a
long one. But that's ok, I can feed the parser in
several times, thanks to the isFinal argument.

The problem I would like to report here is that when
the buffer is not done yet, expat calls the
CharacterDataHandler on the end of the buffer, even if
there is more data for it after the feed boundary. A
log of my test program can be found in attachement. All
charterdataread 12345 for ease of debugging. The "1..k"
strings mean give the first and last char feeded to the
parser at that time.

As you can see, the CharacterDataHandler is called
twice for a->clauses[368].literals[16] the first time
with '1' and the second one with '2345'.  As reported
by the lines indicating the boundaries, that's exactly
where the feed boundaries are.

I really need this one working asap for my job I tryied
to fix it myself, but poorly failed. I know it's an
open source project and the induced rules, so I don't
want to rush you with it. Simply, if you have a fix for
it, would you mind sending it to me so that I can
continue my project, please?

I use the version 1.95.8 of expat, plus the debian
packages patches (I updated the package to make sure
the fix was not already in the newest version without
having to polute my /usr/local).

Of course, I cannot produce a "short but complete XML
document that exhibits a bug that you are reporting".
The bug occure when the file is more than 32kb (maxint).

Thanks a lot for your time,
Mt.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1004302&group_id=10127
From noreply at sourceforge.net  Fri Aug  6 05:12:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug  6 05:12:49 2004
Subject: [Expat-bugs] [ expat-Bugs-1004302 ] CharcterData splitted in the
	middle when isFinal=0
Message-ID: <E1Bsv9w-0004Qo-00@sc8-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Quinson (mquinson)
>Assigned to: Karl Waclawek (kwaclaw)
Summary: CharcterData splitted in the middle when isFinal=0

Initial Comment:
Hello,

I'm trying to use expat on very big document (about
50Mb), so the first bad news is that XML_Parse takes
the size of the buffer as a regular int instead of a
long one. But that's ok, I can feed the parser in
several times, thanks to the isFinal argument.

The problem I would like to report here is that when
the buffer is not done yet, expat calls the
CharacterDataHandler on the end of the buffer, even if
there is more data for it after the feed boundary. A
log of my test program can be found in attachement. All
charterdataread 12345 for ease of debugging. The "1..k"
strings mean give the first and last char feeded to the
parser at that time.

As you can see, the CharacterDataHandler is called
twice for a->clauses[368].literals[16] the first time
with '1' and the second one with '2345'.  As reported
by the lines indicating the boundaries, that's exactly
where the feed boundaries are.

I really need this one working asap for my job I tryied
to fix it myself, but poorly failed. I know it's an
open source project and the induced rules, so I don't
want to rush you with it. Simply, if you have a fix for
it, would you mind sending it to me so that I can
continue my project, please?

I use the version 1.95.8 of expat, plus the debian
packages patches (I updated the package to make sure
the fix was not already in the newest version without
having to polute my /usr/local).

Of course, I cannot produce a "short but complete XML
document that exhibits a bug that you are reporting".
The bug occure when the file is more than 32kb (maxint).

Thanks a lot for your time,
Mt.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2004-08-05 23:12

Message:
Logged In: YES 
user_id=290026

It is a documented  behaviour of Expat that character
data, even if contiguous, may be reported in chunks, that
is, through multiple call-backs. For instance, Expat will
normally call the character data handler when it sees a line 
break, even if there are more characters to come.

I am afraid that the observed behaviour works as designed.
The standard approach for dealing with it is to use a buffer
to accumulate the characters until the next boundary
(start or end of element tag) is encountered.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1004302&group_id=10127
From noreply at sourceforge.net  Fri Aug  6 09:25:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug  6 09:26:11 2004
Subject: [Expat-bugs] [ expat-Bugs-1004302 ] CharcterData splitted in the
	middle when isFinal=0
Message-ID: <E1Bsz6r-0002lN-00@sc8-sf-web4.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Quinson (mquinson)
Assigned to: Karl Waclawek (kwaclaw)
Summary: CharcterData splitted in the middle when isFinal=0

Initial Comment:
Hello,

I'm trying to use expat on very big document (about
50Mb), so the first bad news is that XML_Parse takes
the size of the buffer as a regular int instead of a
long one. But that's ok, I can feed the parser in
several times, thanks to the isFinal argument.

The problem I would like to report here is that when
the buffer is not done yet, expat calls the
CharacterDataHandler on the end of the buffer, even if
there is more data for it after the feed boundary. A
log of my test program can be found in attachement. All
charterdataread 12345 for ease of debugging. The "1..k"
strings mean give the first and last char feeded to the
parser at that time.

As you can see, the CharacterDataHandler is called
twice for a->clauses[368].literals[16] the first time
with '1' and the second one with '2345'.  As reported
by the lines indicating the boundaries, that's exactly
where the feed boundaries are.

I really need this one working asap for my job I tryied
to fix it myself, but poorly failed. I know it's an
open source project and the induced rules, so I don't
want to rush you with it. Simply, if you have a fix for
it, would you mind sending it to me so that I can
continue my project, please?

I use the version 1.95.8 of expat, plus the debian
packages patches (I updated the package to make sure
the fix was not already in the newest version without
having to polute my /usr/local).

Of course, I cannot produce a "short but complete XML
document that exhibits a bug that you are reporting".
The bug occure when the file is more than 32kb (maxint).

Thanks a lot for your time,
Mt.

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

>Comment By: Martin Quinson (mquinson)
Date: 2004-08-06 09:25

Message:
Logged In: YES 
user_id=85746

What, do you mean you put bugs in expat on purpose ? Just
kiding, of course.

Ok, if that's the way to go, that's the way I'll go, even if
that's a real pain in the ass. Why couldn't just expat
buffer this data until it has it all?

I should have RTFM before submitting this bug, sorry. Feel
free to close this "bug"

Thanks for your time, Mt.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-08-06 05:12

Message:
Logged In: YES 
user_id=290026

It is a documented  behaviour of Expat that character
data, even if contiguous, may be reported in chunks, that
is, through multiple call-backs. For instance, Expat will
normally call the character data handler when it sees a line 
break, even if there are more characters to come.

I am afraid that the observed behaviour works as designed.
The standard approach for dealing with it is to use a buffer
to accumulate the characters until the next boundary
(start or end of element tag) is encountered.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1004302&group_id=10127
From noreply at sourceforge.net  Fri Aug  6 15:40:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug  6 15:40:39 2004
Subject: [Expat-bugs] [ expat-Bugs-1004302 ] CharcterData splitted in the
	middle when isFinal=0
Message-ID: <E1Bt4xX-0007QC-00@sc8-sf-web4.sourceforge.net>

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

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Martin Quinson (mquinson)
Assigned to: Karl Waclawek (kwaclaw)
Summary: CharcterData splitted in the middle when isFinal=0

Initial Comment:
Hello,

I'm trying to use expat on very big document (about
50Mb), so the first bad news is that XML_Parse takes
the size of the buffer as a regular int instead of a
long one. But that's ok, I can feed the parser in
several times, thanks to the isFinal argument.

The problem I would like to report here is that when
the buffer is not done yet, expat calls the
CharacterDataHandler on the end of the buffer, even if
there is more data for it after the feed boundary. A
log of my test program can be found in attachement. All
charterdataread 12345 for ease of debugging. The "1..k"
strings mean give the first and last char feeded to the
parser at that time.

As you can see, the CharacterDataHandler is called
twice for a->clauses[368].literals[16] the first time
with '1' and the second one with '2345'.  As reported
by the lines indicating the boundaries, that's exactly
where the feed boundaries are.

I really need this one working asap for my job I tryied
to fix it myself, but poorly failed. I know it's an
open source project and the induced rules, so I don't
want to rush you with it. Simply, if you have a fix for
it, would you mind sending it to me so that I can
continue my project, please?

I use the version 1.95.8 of expat, plus the debian
packages patches (I updated the package to make sure
the fix was not already in the newest version without
having to polute my /usr/local).

Of course, I cannot produce a "short but complete XML
document that exhibits a bug that you are reporting".
The bug occure when the file is more than 32kb (maxint).

Thanks a lot for your time,
Mt.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2004-08-06 09:40

Message:
Logged In: YES 
user_id=290026

I guess the reason is speed.
Most SAX parsers I know of behave exactly the same.

Closing this issue.

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

Comment By: Martin Quinson (mquinson)
Date: 2004-08-06 03:25

Message:
Logged In: YES 
user_id=85746

What, do you mean you put bugs in expat on purpose ? Just
kiding, of course.

Ok, if that's the way to go, that's the way I'll go, even if
that's a real pain in the ass. Why couldn't just expat
buffer this data until it has it all?

I should have RTFM before submitting this bug, sorry. Feel
free to close this "bug"

Thanks for your time, Mt.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-08-05 23:12

Message:
Logged In: YES 
user_id=290026

It is a documented  behaviour of Expat that character
data, even if contiguous, may be reported in chunks, that
is, through multiple call-backs. For instance, Expat will
normally call the character data handler when it sees a line 
break, even if there are more characters to come.

I am afraid that the observed behaviour works as designed.
The standard approach for dealing with it is to use a buffer
to accumulate the characters until the next boundary
(start or end of element tag) is encountered.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1004302&group_id=10127
From noreply at sourceforge.net  Tue Aug 10 18:41:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 10 18:41:25 2004
Subject: [Expat-bugs] [ expat-Bugs-1006708 ] unmatched braces in headers
Message-ID: <E1BuZgg-0001n7-00@sc8-sf-web2.sourceforge.net>

Bugs item #1006708, was opened at 2004-08-10 09:41
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=1006708&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: unmatched braces in headers

Initial Comment:
expat.h contains:
#ifdef __cplusplus
 }
#endif

and expat_external.h contains:
#ifdef __cplusplus
 extern "C" {
#endif

Each file should both open and close these blocks. 
There are some cases where only expat_external.h is
included in the expat sources.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1006708&group_id=10127
From noreply at sourceforge.net  Tue Aug 10 18:42:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 10 18:42:21 2004
Subject: [Expat-bugs] [ expat-Bugs-1006708 ] unmatched braces in headers
Message-ID: <E1BuZhZ-0001nx-00@sc8-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: unmatched braces in headers

Initial Comment:
expat.h contains:
#ifdef __cplusplus
 }
#endif

and expat_external.h contains:
#ifdef __cplusplus
 extern "C" {
#endif

Each file should both open and close these blocks. 
There are some cases where only expat_external.h is
included in the expat sources.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-08-10 09:42

Message:
Logged In: NO 

My name is Jon <mccann@jhu.edu>.  Thanks.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1006708&group_id=10127
From noreply at sourceforge.net  Tue Aug 10 20:22:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 10 20:22:52 2004
Subject: [Expat-bugs] [ expat-Bugs-1006708 ] unmatched braces in headers
Message-ID: <E1BubGq-0004Bv-00@sc8-sf-web1.sourceforge.net>

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

Category: None
>Group: Test Required
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: unmatched braces in headers

Initial Comment:
expat.h contains:
#ifdef __cplusplus
 }
#endif

and expat_external.h contains:
#ifdef __cplusplus
 extern "C" {
#endif

Each file should both open and close these blocks. 
There are some cases where only expat_external.h is
included in the expat sources.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2004-08-10 14:22

Message:
Logged In: YES 
user_id=290026

Fixed in revisions expat.h 1.71 and expat_external.h 1.2.

Needs testing of C++ compilation. Already checked
in a few fixes when doing so under MS VC++ 6.0.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-08-10 12:42

Message:
Logged In: NO 

My name is Jon <mccann@jhu.edu>.  Thanks.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1006708&group_id=10127
From noreply at sourceforge.net  Wed Aug 11 10:04:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 11 10:04:15 2004
Subject: [Expat-bugs] [ expat-Bugs-1007088 ] .DSW/.DSP contain Unix line
	endings in released tarball
Message-ID: <E1Buo5k-00023G-00@sc8-sf-web3.sourceforge.net>

Bugs item #1007088, was opened at 2004-08-11 01:04
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=1007088&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: .DSW/.DSP contain Unix line endings in released tarball

Initial Comment:
Version tested: 1.95.8 
Platform: Windows server 2003 
Compiler: Visual studio .NET 2003 (VC7.1). 
 
Either the .dsw/.dsp files should be converted prior to 
making the tarball, or the readme in the WIn32 directory 
should indicate that line-ending conversion is requred prior 
to opening the project. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1007088&group_id=10127
From noreply at sourceforge.net  Wed Aug 11 10:26:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 11 10:27:01 2004
Subject: [Expat-bugs] [ expat-Bugs-1007100 ] Release and Debug DLLs should
	have different names
Message-ID: <E1BuoRm-0008WK-00@sc8-sf-web4.sourceforge.net>

Bugs item #1007100, was opened at 2004-08-11 01:26
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=1007100&group_id=10127

Category: Build control
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: Release and Debug DLLs should have different names

Initial Comment:
On windows, (unlike on Unix) it is a wise idea to have 
output dlls and libs for release and debug with different 
names, possibly following the Python convention: 
 
python.exe 
python_d.exe 
python23.dll 
python23_d.dll 
etc... 
 
The ACE library is another one: 
ace.dll 
aced.dll 
 
And IBMs unicode libraries  (ICU) follow a similar 
converntion. 
 
The reason for this is that applications may encounter 
runtime errors when linking to libraries that use a different 
heap, and release and debug versions generally do this. 
 
 
 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1007100&group_id=10127
From noreply at sourceforge.net  Wed Aug 11 14:00:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 11 14:00:42 2004
Subject: [Expat-bugs] [ expat-Bugs-1007202 ] Created library does not appear
	to have correct name.
Message-ID: <E1BurmZ-0003wp-00@sc8-sf-web1.sourceforge.net>

Bugs item #1007202, was opened at 2004-08-11 05:00
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=1007202&group_id=10127

Category: Build control
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: Created library does not appear to have correct name.

Initial Comment:
Expat Version: 1.95.8 
Platform: Linux SusE 8.1 
Compiler: gcc 3.3.1 
 
On Linux the configure -> make process creates these files: 
libexpat.so 
libexpat.so.0 
libexpat.so.0.5.0 
 
It is hard to equate 0.5.0 with the Expat version, 1.95.8 
 
This may cause confusion when more than one Expat 
library version resides on the same system. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1007202&group_id=10127
From noreply at sourceforge.net  Wed Aug 11 14:13:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 11 14:13:39 2004
Subject: [Expat-bugs] [ expat-Bugs-780087 ] bad gcc flag when linking
	library in Solaris 2.8
Message-ID: <E1Burz5-0007xS-00@sc8-sf-web2.sourceforge.net>

Bugs item #780087, was opened at 2003-07-30 01:44
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=780087&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: bad gcc flag when linking library in Solaris 2.8

Initial Comment:

expat 1.95.5, 1.95.6

When libtool links the lib/xmlparse.lo lib/xmltok.lo 
lib/xmlrole.lo into libexpat.la on Solaris 2.8 when using 
gcc(3.3 or 3.1), libgcc(3.1 or 3.3) and binutils
(2.11.2) ,from SunFreeware.com,  it includes the '-no-
undefined' flag which causes the make to always fail 
with a &quot;main not found in crt1.o&quot; error.

This of course is silly 'coz a library has no 'main', see gcc 
discusion http://www.geocrawler.com/mail/msg.php3?
msg_id=2903632&amp;list=28. 

Looking at libtools &quot;link&quot; case statement I see it 
sets &quot;allow_undefined=yes&quot; but this does not translate 
to the make line. Could this be a problem?

When I manually edited the &quot;make&quot; line, removing the 
flag '-no-undefined'  the library was built without error.

As this stops expat building from source on the above 
platform can I sugest that this is considered an urgent 
bug to be fixed?

Of course I could be wrong :-) Here's an example (I've 
used 1.95.5 to avoid all those regparm warning 
messages you get in 1.95.6 on Solaris with gcc 3.1/3.3)

snip---

Script started on Wed Jul 30 09:41:53 2003
sh-2.03$ cd expat-1.95.5
sh-2.03$ make distclean ; ./configure ; make
cd lib &amp;&amp; rm -f libexpat.la *.o *.lo &amp;&amp; rm -rf .libs _libs
cd xmlwf &amp;&amp; rm -f xmlwf *.o *.lo &amp;&amp; rm -rf .libs _libs
cd examples &amp;&amp; rm -f elements outline *.o *.lo &amp;&amp; rm -
rf .libs _libs
cd tests &amp;&amp; rm -rf .libs runtests runtests.o chardata.o
rm -rf .libs libexpat.la
find . -name core | xargs rm -f
rm -f expat_config.h config.status config.log 
config.cache libtool
rm -f Makefile
checking build system type... sparc-sun-solaris2.8
checking host system type... sparc-sun-solaris2.8
checking for gcc... /usr/local/bin/gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /usr/local/bin/gcc accepts -g... yes
checking for ld used by GCC... /usr/local/bin/gcc
checking if the linker (/usr/local/bin/gcc) is GNU ld... no
checking for /usr/local/bin/gcc option to reload object 
files... -r
checking for BSD-compatible nm... /usr/local/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependant libraries... pass_all
checking command to parse /usr/local/bin/nm -B 
output... ok
checking how to run the C 
preprocessor... /usr/local/bin/gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... no
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for /usr/local/bin/gcc option to produce PIC... -
fPIC
checking if /usr/local/bin/gcc PIC flag -fPIC works... yes
checking if /usr/local/bin/gcc static flag -static works... 
yes
checking if /usr/local/bin/gcc supports -c -o file.o... yes
checking if /usr/local/bin/gcc supports -c -o file.lo... yes
checking if /usr/local/bin/gcc supports -fno-rtti -fno-
exceptions... yes
checking whether the linker (/usr/local/bin/gcc) supports 
shared libraries... ye
s
checking how to hardcode library paths into programs... 
immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... solaris2.8 ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
creating libtool
checking for gcc... (cached) /usr/local/bin/gcc
checking whether we are using the GNU C compiler... 
(cached) yes
checking whether /usr/local/bin/gcc accepts -g... 
(cached) yes
checking for a BSD-compatible install... conftools/install-
sh -c
checking whether gcc accepts -fexceptions... yes
checking for ANSI C header files... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking for unistd.h... (cached) yes
checking whether byte ordering is bigendian... yes
checking for /usr/local/bin/gcc option to accept ANSI 
C... none needed
checking for an ANSI C-conforming const... yes
checking for off_t... yes
checking for size_t... yes
checking for working memcmp... yes
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for getpagesize... yes
checking for working mmap... yes
checking for memmove... yes
checking for bcopy... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating expat_config.h
/bin/bash ./libtool --silent --
mode=compile /usr/local/bin/gcc -g -O2 -Wall -Wmi
ssing-prototypes -Wstrict-prototypes -fexceptions   -
I./lib -I. -o lib/xmlparse.
lo -c lib/xmlparse.c
/bin/bash ./libtool --silent --
mode=compile /usr/local/bin/gcc -g -O2 -Wall -Wmi
ssing-prototypes -Wstrict-prototypes -fexceptions   -
I./lib -I. -o lib/xmltok.lo
 -c lib/xmltok.c
/bin/bash ./libtool --silent --
mode=compile /usr/local/bin/gcc -g -O2 -Wall -Wmi
ssing-prototypes -Wstrict-prototypes -fexceptions   -
I./lib -I. -o lib/xmlrole.l
o -c lib/xmlrole.c
/bin/bash ./libtool --silent --
mode=link /usr/local/bin/gcc -g -O2 -Wall -Wmissi
ng-prototypes -Wstrict-prototypes -fexceptions   -
I./lib -I. -no-undefined -vers
ion-info 4:0:4 -rpath /usr/local/lib  -o libexpat.la 
lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo
Undefined                       first referenced
 symbol                             in file
main                                /usr/local/lib/gcc-lib/sparc-
sun-solaris2.8/
3.3/crt1.o
ld: fatal: Symbol referencing errors. No output written 
to .libs/libexpat.so.0.4
.0
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `libexpat.la'
sh-2.03$ exit

script done on Wed Jul 30 09:43:53 2003

snip---





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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-08-11 05:13

Message:
Logged In: NO 

I've failed to reproduce this on Solaris 8 with the latest Expat 
version (1.95.8) 
 
Expat: 1.95.8 
Compiler: gcc 3.3.3 
Libtool: 1.5 
 
As an aside, -shared option should be used for linking shared libs 
on Solaris.  -G ends up in the library apparently being linked but 
later errors about failing to find 'main' when linking an 
application.  I can't see either mentioned above though. 
 
Another aside: -O2 is dangerous for some versions of gcc on 
SPARC, in particular 3.3.2, 3.3.3.  -O2 should only be used with 
option -fno-peephole for the paranoid :-). 
 

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-06-08 16:37

Message:
Logged In: NO 

have you resolved this?  I'm having the same problem and 
unable to solve it

Please let me know if you have any glue

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

Comment By: Faye Gibbins (fgibbins)
Date: 2003-11-03 05:04

Message:
Logged In: YES 
user_id=837230

I'm still getting this on Solairs 2.8 with expat 1.95.7

snip---

/bin/bash ./libtool --silent --mode=compile /usr/local/bin/gcc -
g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -
fexceptions -DHAVE_EXPAT_CONFIG_H   -I./lib -I. -o 
lib/xmltok.lo -c lib/xmltok.c
/bin/bash ./libtool --silent --mode=compile /usr/local/bin/gcc -
g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -
fexceptions -DHAVE_EXPAT_CONFIG_H   -I./lib -I. -o 
lib/xmlrole.lo -c lib/xmlrole.c
/bin/bash ./libtool --silent --mode=link /usr/local/bin/gcc -g -
O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -
fexceptions -DHAVE_EXPAT_CONFIG_H   -I./lib -I. -no-
undefined -version-info 5:0:5 -
rpath /home/l347283/tmp/expat/lib  -o libexpat.la 
lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo
Undefined                       first referenced
 symbol                             in file
main                                /usr/local/lib/gcc-lib/sparc-sun-
solaris2.8/3.3/crt1.o
ld: fatal: Symbol referencing errors. No output written 
to .libs/libexpat.so.0.5.0
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `libexpat.la'
[l347283@ifperf expat-1.95.7]$


snip---

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-10-14 12:47

Message:
Logged In: YES 
user_id=3066

There's a snapshot of the current CVS version at:

http://www.libexpat.org/expat-2003-10-11.tar.gz

Can anyone reproduce this using this snapshot?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=780087&group_id=10127
From noreply at sourceforge.net  Fri Aug 13 01:19:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 13 01:19:24 2004
Subject: [Expat-bugs] [ expat-Bugs-1004302 ] CharcterData splitted in the
	middle when isFinal=0
Message-ID: <E1BvOqr-0001r1-00@sc8-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Martin Quinson (mquinson)
Assigned to: Karl Waclawek (kwaclaw)
Summary: CharcterData splitted in the middle when isFinal=0

Initial Comment:
Hello,

I'm trying to use expat on very big document (about
50Mb), so the first bad news is that XML_Parse takes
the size of the buffer as a regular int instead of a
long one. But that's ok, I can feed the parser in
several times, thanks to the isFinal argument.

The problem I would like to report here is that when
the buffer is not done yet, expat calls the
CharacterDataHandler on the end of the buffer, even if
there is more data for it after the feed boundary. A
log of my test program can be found in attachement. All
charterdataread 12345 for ease of debugging. The "1..k"
strings mean give the first and last char feeded to the
parser at that time.

As you can see, the CharacterDataHandler is called
twice for a->clauses[368].literals[16] the first time
with '1' and the second one with '2345'.  As reported
by the lines indicating the boundaries, that's exactly
where the feed boundaries are.

I really need this one working asap for my job I tryied
to fix it myself, but poorly failed. I know it's an
open source project and the induced rules, so I don't
want to rush you with it. Simply, if you have a fix for
it, would you mind sending it to me so that I can
continue my project, please?

I use the version 1.95.8 of expat, plus the debian
packages patches (I updated the package to make sure
the fix was not already in the newest version without
having to polute my /usr/local).

Of course, I cannot produce a "short but complete XML
document that exhibits a bug that you are reporting".
The bug occure when the file is more than 32kb (maxint).

Thanks a lot for your time,
Mt.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-08-12 16:19

Message:
Logged In: NO 

I am a newbie to expat, so my expirience is not very savvy.
I encoutered the same problem with 'character data splitted'
as Martin.

We deal with small portions of up to 4k. Our xml data gets 
served via TCP/IP, where it is simply not garanteed when and 
how the xml data is received could be one or several 
packages. this leads to exact same problem that the 
characterdata handler is called more then one time.

Karl Waclawek describes as a workaround to do the buffering
on the application side. This is pretty inconvinient though 
and not very clean to implement. 

Live would be much easier if a Start- and End-
CharacterDatahandler callback function would be available. 
(like it is for element and CDATA)

I agree with Martin and it should be handled by the expat.
e.g. expat only calls back for attributes if complete.
 
mattes@mykmk.com

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-08-06 06:40

Message:
Logged In: YES 
user_id=290026

I guess the reason is speed.
Most SAX parsers I know of behave exactly the same.

Closing this issue.

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

Comment By: Martin Quinson (mquinson)
Date: 2004-08-06 00:25

Message:
Logged In: YES 
user_id=85746

What, do you mean you put bugs in expat on purpose ? Just
kiding, of course.

Ok, if that's the way to go, that's the way I'll go, even if
that's a real pain in the ass. Why couldn't just expat
buffer this data until it has it all?

I should have RTFM before submitting this bug, sorry. Feel
free to close this "bug"

Thanks for your time, Mt.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-08-05 20:12

Message:
Logged In: YES 
user_id=290026

It is a documented  behaviour of Expat that character
data, even if contiguous, may be reported in chunks, that
is, through multiple call-backs. For instance, Expat will
normally call the character data handler when it sees a line 
break, even if there are more characters to come.

I am afraid that the observed behaviour works as designed.
The standard approach for dealing with it is to use a buffer
to accumulate the characters until the next boundary
(start or end of element tag) is encountered.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1004302&group_id=10127
From noreply at sourceforge.net  Fri Aug 13 01:32:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 13 01:32:39 2004
Subject: [Expat-bugs] [ expat-Bugs-1004302 ] CharcterData splitted in the
	middle when isFinal=0
Message-ID: <E1BvP3i-0002Y4-00@sc8-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Martin Quinson (mquinson)
Assigned to: Karl Waclawek (kwaclaw)
Summary: CharcterData splitted in the middle when isFinal=0

Initial Comment:
Hello,

I'm trying to use expat on very big document (about
50Mb), so the first bad news is that XML_Parse takes
the size of the buffer as a regular int instead of a
long one. But that's ok, I can feed the parser in
several times, thanks to the isFinal argument.

The problem I would like to report here is that when
the buffer is not done yet, expat calls the
CharacterDataHandler on the end of the buffer, even if
there is more data for it after the feed boundary. A
log of my test program can be found in attachement. All
charterdataread 12345 for ease of debugging. The "1..k"
strings mean give the first and last char feeded to the
parser at that time.

As you can see, the CharacterDataHandler is called
twice for a->clauses[368].literals[16] the first time
with '1' and the second one with '2345'.  As reported
by the lines indicating the boundaries, that's exactly
where the feed boundaries are.

I really need this one working asap for my job I tryied
to fix it myself, but poorly failed. I know it's an
open source project and the induced rules, so I don't
want to rush you with it. Simply, if you have a fix for
it, would you mind sending it to me so that I can
continue my project, please?

I use the version 1.95.8 of expat, plus the debian
packages patches (I updated the package to make sure
the fix was not already in the newest version without
having to polute my /usr/local).

Of course, I cannot produce a "short but complete XML
document that exhibits a bug that you are reporting".
The bug occure when the file is more than 32kb (maxint).

Thanks a lot for your time,
Mt.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2004-08-12 19:32

Message:
Logged In: YES 
user_id=290026

Changing the behaviour would mean major surgery in Expat 
and is unlikely to happen.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-08-12 19:19

Message:
Logged In: NO 

I am a newbie to expat, so my expirience is not very savvy.
I encoutered the same problem with 'character data splitted'
as Martin.

We deal with small portions of up to 4k. Our xml data gets 
served via TCP/IP, where it is simply not garanteed when and 
how the xml data is received could be one or several 
packages. this leads to exact same problem that the 
characterdata handler is called more then one time.

Karl Waclawek describes as a workaround to do the buffering
on the application side. This is pretty inconvinient though 
and not very clean to implement. 

Live would be much easier if a Start- and End-
CharacterDatahandler callback function would be available. 
(like it is for element and CDATA)

I agree with Martin and it should be handled by the expat.
e.g. expat only calls back for attributes if complete.
 
mattes@mykmk.com

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-08-06 09:40

Message:
Logged In: YES 
user_id=290026

I guess the reason is speed.
Most SAX parsers I know of behave exactly the same.

Closing this issue.

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

Comment By: Martin Quinson (mquinson)
Date: 2004-08-06 03:25

Message:
Logged In: YES 
user_id=85746

What, do you mean you put bugs in expat on purpose ? Just
kiding, of course.

Ok, if that's the way to go, that's the way I'll go, even if
that's a real pain in the ass. Why couldn't just expat
buffer this data until it has it all?

I should have RTFM before submitting this bug, sorry. Feel
free to close this "bug"

Thanks for your time, Mt.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-08-05 23:12

Message:
Logged In: YES 
user_id=290026

It is a documented  behaviour of Expat that character
data, even if contiguous, may be reported in chunks, that
is, through multiple call-backs. For instance, Expat will
normally call the character data handler when it sees a line 
break, even if there are more characters to come.

I am afraid that the observed behaviour works as designed.
The standard approach for dealing with it is to use a buffer
to accumulate the characters until the next boundary
(start or end of element tag) is encountered.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1004302&group_id=10127
From noreply at sourceforge.net  Fri Aug 13 03:16:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 13 03:16:34 2004
Subject: [Expat-bugs] [ expat-Bugs-1004302 ] CharcterData splitted in the
	middle when isFinal=0
Message-ID: <E1BvQgH-0003lG-00@sc8-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Martin Quinson (mquinson)
Assigned to: Karl Waclawek (kwaclaw)
Summary: CharcterData splitted in the middle when isFinal=0

Initial Comment:
Hello,

I'm trying to use expat on very big document (about
50Mb), so the first bad news is that XML_Parse takes
the size of the buffer as a regular int instead of a
long one. But that's ok, I can feed the parser in
several times, thanks to the isFinal argument.

The problem I would like to report here is that when
the buffer is not done yet, expat calls the
CharacterDataHandler on the end of the buffer, even if
there is more data for it after the feed boundary. A
log of my test program can be found in attachement. All
charterdataread 12345 for ease of debugging. The "1..k"
strings mean give the first and last char feeded to the
parser at that time.

As you can see, the CharacterDataHandler is called
twice for a->clauses[368].literals[16] the first time
with '1' and the second one with '2345'.  As reported
by the lines indicating the boundaries, that's exactly
where the feed boundaries are.

I really need this one working asap for my job I tryied
to fix it myself, but poorly failed. I know it's an
open source project and the induced rules, so I don't
want to rush you with it. Simply, if you have a fix for
it, would you mind sending it to me so that I can
continue my project, please?

I use the version 1.95.8 of expat, plus the debian
packages patches (I updated the package to make sure
the fix was not already in the newest version without
having to polute my /usr/local).

Of course, I cannot produce a "short but complete XML
document that exhibits a bug that you are reporting".
The bug occure when the file is more than 32kb (maxint).

Thanks a lot for your time,
Mt.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-08-12 18:16

Message:
Logged In: NO 

Karl, how about an End-CharacterDataHandler()? Would that 
be feasable? Would make the xml pasring much more secure, 
knowing the exact end, to pass on the Character data

mattes


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-08-12 16:32

Message:
Logged In: YES 
user_id=290026

Changing the behaviour would mean major surgery in Expat 
and is unlikely to happen.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-08-12 16:19

Message:
Logged In: NO 

I am a newbie to expat, so my expirience is not very savvy.
I encoutered the same problem with 'character data splitted'
as Martin.

We deal with small portions of up to 4k. Our xml data gets 
served via TCP/IP, where it is simply not garanteed when and 
how the xml data is received could be one or several 
packages. this leads to exact same problem that the 
characterdata handler is called more then one time.

Karl Waclawek describes as a workaround to do the buffering
on the application side. This is pretty inconvinient though 
and not very clean to implement. 

Live would be much easier if a Start- and End-
CharacterDatahandler callback function would be available. 
(like it is for element and CDATA)

I agree with Martin and it should be handled by the expat.
e.g. expat only calls back for attributes if complete.
 
mattes@mykmk.com

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-08-06 06:40

Message:
Logged In: YES 
user_id=290026

I guess the reason is speed.
Most SAX parsers I know of behave exactly the same.

Closing this issue.

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

Comment By: Martin Quinson (mquinson)
Date: 2004-08-06 00:25

Message:
Logged In: YES 
user_id=85746

What, do you mean you put bugs in expat on purpose ? Just
kiding, of course.

Ok, if that's the way to go, that's the way I'll go, even if
that's a real pain in the ass. Why couldn't just expat
buffer this data until it has it all?

I should have RTFM before submitting this bug, sorry. Feel
free to close this "bug"

Thanks for your time, Mt.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-08-05 20:12

Message:
Logged In: YES 
user_id=290026

It is a documented  behaviour of Expat that character
data, even if contiguous, may be reported in chunks, that
is, through multiple call-backs. For instance, Expat will
normally call the character data handler when it sees a line 
break, even if there are more characters to come.

I am afraid that the observed behaviour works as designed.
The standard approach for dealing with it is to use a buffer
to accumulate the characters until the next boundary
(start or end of element tag) is encountered.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1004302&group_id=10127
From noreply at sourceforge.net  Fri Aug 13 03:18:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 13 03:18:51 2004
Subject: [Expat-bugs] [ expat-Bugs-1004302 ] CharcterData split in the middle
Message-ID: <E1BvQiS-0001RJ-00@sc8-sf-web4.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Martin Quinson (mquinson)
Assigned to: Karl Waclawek (kwaclaw)
>Summary: CharcterData split in the middle

Initial Comment:
Hello,

I'm trying to use expat on very big document (about
50Mb), so the first bad news is that XML_Parse takes
the size of the buffer as a regular int instead of a
long one. But that's ok, I can feed the parser in
several times, thanks to the isFinal argument.

The problem I would like to report here is that when
the buffer is not done yet, expat calls the
CharacterDataHandler on the end of the buffer, even if
there is more data for it after the feed boundary. A
log of my test program can be found in attachement. All
charterdataread 12345 for ease of debugging. The "1..k"
strings mean give the first and last char feeded to the
parser at that time.

As you can see, the CharacterDataHandler is called
twice for a->clauses[368].literals[16] the first time
with '1' and the second one with '2345'.  As reported
by the lines indicating the boundaries, that's exactly
where the feed boundaries are.

I really need this one working asap for my job I tryied
to fix it myself, but poorly failed. I know it's an
open source project and the induced rules, so I don't
want to rush you with it. Simply, if you have a fix for
it, would you mind sending it to me so that I can
continue my project, please?

I use the version 1.95.8 of expat, plus the debian
packages patches (I updated the package to make sure
the fix was not already in the newest version without
having to polute my /usr/local).

Of course, I cannot produce a "short but complete XML
document that exhibits a bug that you are reporting".
The bug occure when the file is more than 32kb (maxint).

Thanks a lot for your time,
Mt.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-08-12 21:18

Message:
Logged In: YES 
user_id=3066

While there's some convenience for the application developer
to be had by providing the buffering directly in Expat, this
would force all applications to pay for the overhead, and
not all applications need to buffer character data.

I'll note that I added application-controlled buffering in
the Python wrapper for Expat; it's not particularly
difficult to write a reasonable buffering implementation. 
One of the issues with doing so, however, is that some space
is needed in the application's data structure that's tacked
onto the Parser object using XML_SetUserData(); not
requiring this would require adding more overhead to the
parser implementation in some form.

Perhaps what's required is better documentation and sample
code, so that everyone has a reasonable starting point to
work from.  This might be made especially easy to re-use for
C99 users.  If that's reasonable, we can re-open this as a
documentation request (assigned to me).

I've tried to clarify the issue summary.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-08-12 21:16

Message:
Logged In: NO 

Karl, how about an End-CharacterDataHandler()? Would that 
be feasable? Would make the xml pasring much more secure, 
knowing the exact end, to pass on the Character data

mattes


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-08-12 19:32

Message:
Logged In: YES 
user_id=290026

Changing the behaviour would mean major surgery in Expat 
and is unlikely to happen.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-08-12 19:19

Message:
Logged In: NO 

I am a newbie to expat, so my expirience is not very savvy.
I encoutered the same problem with 'character data splitted'
as Martin.

We deal with small portions of up to 4k. Our xml data gets 
served via TCP/IP, where it is simply not garanteed when and 
how the xml data is received could be one or several 
packages. this leads to exact same problem that the 
characterdata handler is called more then one time.

Karl Waclawek describes as a workaround to do the buffering
on the application side. This is pretty inconvinient though 
and not very clean to implement. 

Live would be much easier if a Start- and End-
CharacterDatahandler callback function would be available. 
(like it is for element and CDATA)

I agree with Martin and it should be handled by the expat.
e.g. expat only calls back for attributes if complete.
 
mattes@mykmk.com

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-08-06 09:40

Message:
Logged In: YES 
user_id=290026

I guess the reason is speed.
Most SAX parsers I know of behave exactly the same.

Closing this issue.

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

Comment By: Martin Quinson (mquinson)
Date: 2004-08-06 03:25

Message:
Logged In: YES 
user_id=85746

What, do you mean you put bugs in expat on purpose ? Just
kiding, of course.

Ok, if that's the way to go, that's the way I'll go, even if
that's a real pain in the ass. Why couldn't just expat
buffer this data until it has it all?

I should have RTFM before submitting this bug, sorry. Feel
free to close this "bug"

Thanks for your time, Mt.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-08-05 23:12

Message:
Logged In: YES 
user_id=290026

It is a documented  behaviour of Expat that character
data, even if contiguous, may be reported in chunks, that
is, through multiple call-backs. For instance, Expat will
normally call the character data handler when it sees a line 
break, even if there are more characters to come.

I am afraid that the observed behaviour works as designed.
The standard approach for dealing with it is to use a buffer
to accumulate the characters until the next boundary
(start or end of element tag) is encountered.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1004302&group_id=10127
From noreply at sourceforge.net  Tue Aug 17 17:14:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 17 17:15:14 2004
Subject: [Expat-bugs] [ expat-Bugs-1010793 ] build fails on Solaris 8
Message-ID: <E1Bx5fr-0000Aw-00@sc8-sf-web2.sourceforge.net>

Bugs item #1010793, was opened at 2004-08-17 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=1010793&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: build fails on Solaris 8

Initial Comment:
Submitted by: Ave.Wrigley@itn.co.uk

> uname -a
SunOS www1 5.8 Generic_117000-03 sun4u sparc
SUNW,Ultra-4 Solaris
> ./configure
checking build system type... sparc-sun-solaris2.8
checking host system type... sparc-sun-solaris2.8
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for ld used by GCC... /usr/ccs/bin/ld
checking if the linker (/usr/ccs/bin/ld) is GNU ld... no
checking for /usr/ccs/bin/ld option to reload object
files... -r
checking for BSD-compatible nm... /usr/local/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependant libraries... pass_all
checking command to parse /usr/local/bin/nm -B output... ok
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... no
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking whether the linker (/usr/ccs/bin/ld) supports
shared libraries... yes
checking how to hardcode library paths into programs...
immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... solaris2.8 ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
creating libtool
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler...
(cached) yes
checking whether gcc accepts -g... (cached) yes
checking for a BSD-compatible install...
/usr/local/bin/install -c
checking whether gcc accepts -fexceptions... yes
checking for ANSI C header files... (cached) yes
checking whether byte ordering is bigendian... yes
checking for gcc option to accept ANSI C... none needed
checking for an ANSI C-conforming const... yes
checking for size_t... yes
checking for memmove... yes
checking for bcopy... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking for unistd.h... (cached) yes
checking for off_t... yes
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for getpagesize... yes
checking for working mmap... yes
checking check.h usability... no
checking check.h presence... no
checking for check.h... no
checking for check.h... (cached) no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating expat_config.h
config.status: expat_config.h is unchanged
> make
/bin/bash ./libtool --silent --mode=compile gcc -g -O2
-Wall -Wmissing-prototypes -Wstrict-prototypes
-fexceptions -DHAVE_EXPAT_CONFIG_H   -I./lib -I. -o
lib/xmlparse.lo -c lib/xmlparse.c
/bin/bash ./libtool --silent --mode=compile gcc -g -O2
-Wall -Wmissing-prototypes -Wstrict-prototypes
-fexceptions -DHAVE_EXPAT_CONFIG_H   -I./lib -I. -o
lib/xmltok.lo -c lib/xmltok.c
/bin/bash ./libtool --silent --mode=compile gcc -g -O2
-Wall -Wmissing-prototypes -Wstrict-prototypes
-fexceptions -DHAVE_EXPAT_CONFIG_H   -I./lib -I. -o
lib/xmlrole.lo -c lib/xmlrole.c
/bin/bash ./libtool --silent --mode=link gcc -g -O2
-Wall -Wmissing-prototypes -Wstrict-prototypes
-fexceptions -DHAVE_EXPAT_CONFIG_H   -I./lib -I.
-no-undefined -version-info 5:0:5 -rpath /usr/local/lib
 -o libexpat.la lib/xmlparse.lo lib/xmltok.lo
lib/xmlrole.lo
Undefined                       first referenced
 symbol                             in file
__eprintf                           lib/xmlparse.lo
ld: fatal: Symbol referencing errors. No output written
to .libs/libexpat.so.0.5.0
make: *** [libexpat.la] Error 1


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1010793&group_id=10127
From noreply at sourceforge.net  Thu Aug 26 16:05:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 26 16:05:50 2004
Subject: [Expat-bugs] [ expat-Bugs-1016890 ] Not Installing xmlparse.h
Message-ID: <E1C0Ksb-0003qS-00@sc8-sf-web2.sourceforge.net>

Bugs item #1016890, was opened at 2004-08-26 07:05
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=1016890&group_id=10127

Category: Build control
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: Not Installing xmlparse.h

Initial Comment:
Building Expat1.95.8 on a Solaris machine with gcc 
3.4.1 installed.  Fails to copy/install xmlparse.h.  To 
be run with RATS 2.1.  

tom.j.lee@lmco.com
817-763-6541

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1016890&group_id=10127
From noreply at sourceforge.net  Thu Aug 26 16:24:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 26 16:24:34 2004
Subject: [Expat-bugs] [ expat-Bugs-1016890 ] Not Installing xmlparse.h
Message-ID: <E1C0LAy-0005Zr-00@sc8-sf-web4.sourceforge.net>

Bugs item #1016890, was opened at 2004-08-26 10:05
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1016890&group_id=10127

Category: Build control
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: Not Installing xmlparse.h

Initial Comment:
Building Expat1.95.8 on a Solaris machine with gcc 
3.4.1 installed.  Fails to copy/install xmlparse.h.  To 
be run with RATS 2.1.  

tom.j.lee@lmco.com
817-763-6541

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-08-26 10:24

Message:
Logged In: YES 
user_id=3066

1.95.x versions of Expat do not provide xmlparse.h; please use 
expat.h instead.  This is not a recent change. 

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

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