From noreply@sourceforge.net  Mon Jul  1 09:31:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul  1 08:31:36 2002
Subject: [ expat-Bugs-575168 ] Missing events for end-element
Message-ID: <E17P38e-0004Hn-00@usw-sf-web5.sourceforge.net>

Bugs item #575168, was opened at 2002-06-28 15:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=575168&group_id=10127

Category: None
Group: None
>Status: Open
Resolution: Fixed
>Priority: 7
Submitted By: Fred L. Drake, Jr. (fdrake)
>Assigned to: Karl Waclawek (kwaclaw)
Summary: Missing events for end-element

Initial Comment:
When the end-element handler is set but not the
start-element handler, the end-element events for end
tags are not reported; events are reported for empty
elements.

I've attached a test case that demonstrates this problem.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-01 11:30

Message:
Logged In: YES 
user_id=3066

Karl, the additional patch looks good to me; go ahead and
check it in, and I'll finish up the hard-tab removal task.

Re-close the bug report when you're ready.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-06-29 23:46

Message:
Logged In: YES 
user_id=290026

I attached a patch (based on your patch - xmlparse.c 1.46),
that always sets up the tag structure, as suggested.
Additionally, I made sure that storeAtts doesn't get
called twice - I moved it under if (startElementHandler) ...

That way we should have correct behaviour, even if the
endElementHandler gets set after the startElementHandler
was called. Since tag->name.str should now always be
non-NULL, I removed the corresponding check.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-06-29 12:26

Message:
Logged In: YES 
user_id=290026

I agree with your analysis, also with the need
for checking other handler pairs.

One quick idea, without looking at the source:

If we remove this check:
...
if (startElementHandler || endElementHandler) {
...
then the tag structure gets always set up  and we
would not need the extra check for endElementHandler.
At the cost of extra processing time, but how
often does one *not* set any of the element handlers?

Karl

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-29 11:17

Message:
Logged In: YES 
user_id=3066

Ok, I've thought about that a bit, and the tests pass with
that change, but I think that means we're missing a test.

I suspect the current implementation largely assumes that
once we start parsing, the set of handlers will not grow;
while this may be reasonable application behavior, this is a
bad assumption to make in library code.

Consider this: some processor watches for a processing
instruction, and *adds* handlers based on that.  Suppose
that it adds start/end element handlers where it had none
before, and the document looks like this:

<doc>
    <?mytool start?>
    <inner/>
</doc>

If we make the change you suggest, we could be passing bad
data (NULL for the tagName) to the endElementHandler for the
doc element, though all will be fine for the inner element.
 With the extra check in there, it means we don't call the
endElementHandler for the doc element, which, while a bug,
means we're preserving existing behavior instead of passing
NULL (not documented as a valid value for the tagName).

I think we should leave the extra check in for now, but
should consider always setting up the TAG structure, even
though it means extra work for the rare application that
doesn't use either the start or end element handler.  The
data is still potentially needed for any application that
add an endElementHandler after processing starts.

There are probably similar cases for paired handlers
elsewhere in the code as well.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-06-28 19:51

Message:
Logged In: YES 
user_id=290026

Should it not now be possible to change


...
  if (endElementHandler && tag->name.str) {
...

to

...
  if (endElementHandler) {
...

since the code should guarantee that the correct
tag is accessed, which means that tag->name.str != NULL?

Karl

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-28 19:06

Message:
Logged In: YES 
user_id=3066

I've gone ahead and checked in the patches as lib/xmlparse.c
1.46 and tests/runtests.c 1.23.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-28 17:19

Message:
Logged In: YES 
user_id=3066

I've attached a minimal patch to make Expat generate the
required events.  The attached test passes when this patch
has been applied as well.  The tests of the Python bindings
that originally uncovered this bug also pass with this
change to xmlparse.c.

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

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


From noreply@sourceforge.net  Mon Jul  1 15:09:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul  1 14:09:32 2002
Subject: [ expat-Bugs-570903 ] Remove tabs in sources
Message-ID: <E17P8Pc-00029l-00@usw-sf-web2.sourceforge.net>

Bugs item #570903, was opened at 2002-06-18 22:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=570903&group_id=10127

Category: None
Group: Feature Request
Status: Open
Resolution: None
Priority: 7
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Remove tabs in sources

Initial Comment:
All hard tabs should be removed from the source files.
This is a release requirement for Expat 1.95.4; the
changes will be made while preparing for the final release.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-01 17:08

Message:
Logged In: YES 
user_id=3066

Almost complete; only lib/xmlparse.c remains to be done. 
Waiting for other developers to finish checking in
outstanding patches.

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

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


From noreply@sourceforge.net  Tue Jul  2 08:25:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul  2 07:25:12 2002
Subject: [ expat-Bugs-576396 ] expat 1.95.3 fails to build on aix 4.3.3
Message-ID: <E17PORN-0008UY-00@usw-sf-web2.sourceforge.net>

Bugs item #576396, was opened at 2002-07-02 07:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=576396&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: expat 1.95.3 fails to build on aix 4.3.3

Initial Comment:
Hi everybody,

when attempting to build expat 1.95.3 on aix 4.3.3,
i had the following error running 'make'

/bin/sh ./libtool --silent --mode=compile cc -g   -Ilib -I. -o 
lib/xmlparse.lo -
c lib/xmlparse.c
/bin/sh ./libtool --silent --mode=compile cc -g   -Ilib -I. -o 
lib/xmltok.lo -c
lib/xmltok.c
/bin/sh ./libtool --silent --mode=compile cc -g   -Ilib -I. -o 
lib/xmlrole.lo -c
 lib/xmlrole.c
/bin/sh ./libtool --silent --mode=link cc -g   -Ilib -I. -no-
undefined -version-
info 2:0:2 -rpath /usr/test/lib  -o lib/libexpat.la 
lib/xmlparse.lo lib/xmltok.l
o lib/xmlrole.lo
ar: No such file or directory
ar: 0707-113 The fopen system call failed on 
file .libs/libexpat.a.
make: *** [lib/libexpat.la] Erreur 1

I searched the web and found a similar error with a 
solution described in

http://www.freetype.org/pipermail/devel/2002-
March/003045.html

<quote>
The problem was the AR was being passed $objdir, when 
it should be $output_objdir. The former is a relative path, 
and we need an absolute path.
</quote>

It' a 'configure' issue
I tried it and it works !
I also succeeded to build perl module XML::Parser 2-31
:-)

I've sent the patch as an attachment

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

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


From noreply@sourceforge.net  Tue Jul  2 08:46:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul  2 07:46:09 2002
Subject: [ expat-Patches-576406 ] [ 576396 ] expat 1.95.3 on aix 4.3.3
Message-ID: <E17POjo-0001pc-00@usw-sf-web1.sourceforge.net>

Patches item #576406, was opened at 2002-07-02 11:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=576406&group_id=10127

Category: Build Control
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: José AUGUSTE-ETIENNE (joseae)
Assigned to: Greg Stein (gstein)
Summary: [ 576396 ] expat 1.95.3 on aix 4.3.3

Initial Comment:
[ 576396 ] expat 1.95.3 fails to build on aix 4.3.3

this patch modifies 'configure' by passing $output_objdir
instead of $objdir to AR

I hope there won't be line wrapping problems,
since upload/attachements don't seem to work

José

--- begin of patch ---
--- configure.orig	2002-07-02 
09:33:45.000000000 -0300
+++ configure	2002-07-02 
09:34:44.000000000 -0300
@@ -4881,7 +4881,7 @@
         allow_undefined_flag='${wl}-berok'
         # This is a bit strange, but is similar to how AIX 
traditionally builds
         # it's shared libraries.
-        archive_expsym_cmds="\ $shared_flag"' -o 
$output_objdir/$soname $libobjs $deplibs $compiler_flags 
${allow_undefined_flag} '"\$no_entry_flag \
$exp_sym_flag:\"' ~$AR -crlo $objdir/
$libname$release.a $objdir/$soname'
+        archive_expsym_cmds="\ $shared_flag"' -o 
$output_objdir/$soname $libobjs $deplibs $compiler_flags 
${allow_undefined_flag} '"\$no_entry_flag \
$exp_sym_flag:\"' ~$AR -crlo 
$output_objdir/$libname$release.a $output_objdir/
$soname'
       fi
     fi
     ;;
--- end of patch ---

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

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


From noreply@sourceforge.net  Tue Jul  2 08:59:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul  2 07:59:50 2002
Subject: [ expat-Bugs-576396 ] expat 1.95.3 fails to build on aix 4.3.3
Message-ID: <E17PP1c-0003on-00@usw-sf-web4.sourceforge.net>

Bugs item #576396, was opened at 2002-07-02 11:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=576396&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: expat 1.95.3 fails to build on aix 4.3.3

Initial Comment:
Hi everybody,

when attempting to build expat 1.95.3 on aix 4.3.3,
i had the following error running 'make'

/bin/sh ./libtool --silent --mode=compile cc -g   -Ilib -I. -o 
lib/xmlparse.lo -
c lib/xmlparse.c
/bin/sh ./libtool --silent --mode=compile cc -g   -Ilib -I. -o 
lib/xmltok.lo -c
lib/xmltok.c
/bin/sh ./libtool --silent --mode=compile cc -g   -Ilib -I. -o 
lib/xmlrole.lo -c
 lib/xmlrole.c
/bin/sh ./libtool --silent --mode=link cc -g   -Ilib -I. -no-
undefined -version-
info 2:0:2 -rpath /usr/test/lib  -o lib/libexpat.la 
lib/xmlparse.lo lib/xmltok.l
o lib/xmlrole.lo
ar: No such file or directory
ar: 0707-113 The fopen system call failed on 
file .libs/libexpat.a.
make: *** [lib/libexpat.la] Erreur 1

I searched the web and found a similar error with a 
solution described in

http://www.freetype.org/pipermail/devel/2002-
March/003045.html

<quote>
The problem was the AR was being passed $objdir, when 
it should be $output_objdir. The former is a relative path, 
and we need an absolute path.
</quote>

It' a 'configure' issue
I tried it and it works !
I also succeeded to build perl module XML::Parser 2-31
:-)

I've sent the patch as an attachment

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

Comment By: José AUGUSTE-ETIENNE (joseae)
Date: 2002-07-02 11:53

Message:
Logged In: YES 
user_id=571932

The attachment did not work the first time.
See the attachment for Patch #  576406 on "Patches" page

José

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

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


From noreply@sourceforge.net  Tue Jul  2 09:40:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul  2 08:40:44 2002
Subject: [ expat-Patches-576406 ] [ 576396 ] expat 1.95.3 on aix 4.3.3
Message-ID: <E17PPcE-0001vQ-00@usw-sf-web5.sourceforge.net>

Patches item #576406, was opened at 2002-07-02 10:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=576406&group_id=10127

Category: Build Control
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: José AUGUSTE-ETIENNE (joseae)
Assigned to: Greg Stein (gstein)
Summary: [ 576396 ] expat 1.95.3 on aix 4.3.3

Initial Comment:
[ 576396 ] expat 1.95.3 fails to build on aix 4.3.3

this patch modifies 'configure' by passing $output_objdir
instead of $objdir to AR

I hope there won't be line wrapping problems,
since upload/attachements don't seem to work

José

--- begin of patch ---
--- configure.orig	2002-07-02 
09:33:45.000000000 -0300
+++ configure	2002-07-02 
09:34:44.000000000 -0300
@@ -4881,7 +4881,7 @@
         allow_undefined_flag='${wl}-berok'
         # This is a bit strange, but is similar to how AIX 
traditionally builds
         # it's shared libraries.
-        archive_expsym_cmds="\ $shared_flag"' -o 
$output_objdir/$soname $libobjs $deplibs $compiler_flags 
${allow_undefined_flag} '"\$no_entry_flag \
$exp_sym_flag:\"' ~$AR -crlo $objdir/
$libname$release.a $objdir/$soname'
+        archive_expsym_cmds="\ $shared_flag"' -o 
$output_objdir/$soname $libobjs $deplibs $compiler_flags 
${allow_undefined_flag} '"\$no_entry_flag \
$exp_sym_flag:\"' ~$AR -crlo 
$output_objdir/$libname$release.a $output_objdir/
$soname'
       fi
     fi
     ;;
--- end of patch ---

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-02 11:30

Message:
Logged In: YES 
user_id=3066

"configure" is a generated file; "configure.in" is where
changes need to be made.  Unfortunately, this doesn't appear
to have a simple mapping from the configure.in file.

I wonder if this is a problem with autoconf not knowing
enough about AIX?

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

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


From noreply@sourceforge.net  Tue Jul  2 12:48:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul  2 11:48:15 2002
Subject: [ expat-Bugs-575168 ] Missing events for end-element
Message-ID: <E17PSfV-0004FS-00@usw-sf-web2.sourceforge.net>

Bugs item #575168, was opened at 2002-06-28 15:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=575168&group_id=10127

Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Missing events for end-element

Initial Comment:
When the end-element handler is set but not the
start-element handler, the end-element events for end
tags are not reported; events are reported for empty
elements.

I've attached a test case that demonstrates this problem.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-02 14:46

Message:
Logged In: YES 
user_id=290026

Additional patch checked in.

Karl

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-01 11:30

Message:
Logged In: YES 
user_id=3066

Karl, the additional patch looks good to me; go ahead and
check it in, and I'll finish up the hard-tab removal task.

Re-close the bug report when you're ready.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-06-29 23:46

Message:
Logged In: YES 
user_id=290026

I attached a patch (based on your patch - xmlparse.c 1.46),
that always sets up the tag structure, as suggested.
Additionally, I made sure that storeAtts doesn't get
called twice - I moved it under if (startElementHandler) ...

That way we should have correct behaviour, even if the
endElementHandler gets set after the startElementHandler
was called. Since tag->name.str should now always be
non-NULL, I removed the corresponding check.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-06-29 12:26

Message:
Logged In: YES 
user_id=290026

I agree with your analysis, also with the need
for checking other handler pairs.

One quick idea, without looking at the source:

If we remove this check:
...
if (startElementHandler || endElementHandler) {
...
then the tag structure gets always set up  and we
would not need the extra check for endElementHandler.
At the cost of extra processing time, but how
often does one *not* set any of the element handlers?

Karl

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-29 11:17

Message:
Logged In: YES 
user_id=3066

Ok, I've thought about that a bit, and the tests pass with
that change, but I think that means we're missing a test.

I suspect the current implementation largely assumes that
once we start parsing, the set of handlers will not grow;
while this may be reasonable application behavior, this is a
bad assumption to make in library code.

Consider this: some processor watches for a processing
instruction, and *adds* handlers based on that.  Suppose
that it adds start/end element handlers where it had none
before, and the document looks like this:

<doc>
    <?mytool start?>
    <inner/>
</doc>

If we make the change you suggest, we could be passing bad
data (NULL for the tagName) to the endElementHandler for the
doc element, though all will be fine for the inner element.
 With the extra check in there, it means we don't call the
endElementHandler for the doc element, which, while a bug,
means we're preserving existing behavior instead of passing
NULL (not documented as a valid value for the tagName).

I think we should leave the extra check in for now, but
should consider always setting up the TAG structure, even
though it means extra work for the rare application that
doesn't use either the start or end element handler.  The
data is still potentially needed for any application that
add an endElementHandler after processing starts.

There are probably similar cases for paired handlers
elsewhere in the code as well.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-06-28 19:51

Message:
Logged In: YES 
user_id=290026

Should it not now be possible to change


...
  if (endElementHandler && tag->name.str) {
...

to

...
  if (endElementHandler) {
...

since the code should guarantee that the correct
tag is accessed, which means that tag->name.str != NULL?

Karl

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-28 19:06

Message:
Logged In: YES 
user_id=3066

I've gone ahead and checked in the patches as lib/xmlparse.c
1.46 and tests/runtests.c 1.23.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-28 17:19

Message:
Logged In: YES 
user_id=3066

I've attached a minimal patch to make Expat generate the
required events.  The attached test passes when this patch
has been applied as well.  The tests of the Python bindings
that originally uncovered this bug also pass with this
change to xmlparse.c.

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

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


From noreply@sourceforge.net  Thu Jul  4 14:29:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu Jul  4 13:29:03 2002
Subject: [ expat-Bugs-577560 ] xmlparse.h missing
Message-ID: <E17QDDf-0001SO-00@usw-sf-web5.sourceforge.net>

Bugs item #577560, was opened at 2002-07-04 22:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=577560&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joern P. Meier (ionflux)
Assigned to: Nobody/Anonymous (nobody)
Summary: xmlparse.h missing

Initial Comment:
Please include xmlparse/xmlparse.h in the distribution. It 
appears that Python 2.2.1 won't build the expat module if it 
cannot find the header.

Python expat support is required to build libglade expat support, 
which is in turn needed to build gdm-2.4.0.0, which is required 
by GNOME 2.

(I was able to workaround by downloading xmlparse.h from CVS)

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

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


From noreply@sourceforge.net  Thu Jul  4 21:07:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu Jul  4 20:07:04 2002
Subject: [ expat-Bugs-577560 ] xmlparse.h missing
Message-ID: <E17QJQc-0004yo-00@usw-sf-web1.sourceforge.net>

Bugs item #577560, was opened at 2002-07-04 16:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=577560&group_id=10127

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Joern P. Meier (ionflux)
Assigned to: Nobody/Anonymous (nobody)
Summary: xmlparse.h missing

Initial Comment:
Please include xmlparse/xmlparse.h in the distribution. It 
appears that Python 2.2.1 won't build the expat module if it 
cannot find the header.

Python expat support is required to build libglade expat support, 
which is in turn needed to build gdm-2.4.0.0, which is required 
by GNOME 2.

(I was able to workaround by downloading xmlparse.h from CVS)

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-04 23:06

Message:
Logged In: YES 
user_id=290026

xmlparse.h is not a part of Expat anymore.
You should get the most recent version of Expat,
i.e. the current version from CVS.

Closed, since this is not a bug.

Karl

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

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


From noreply@sourceforge.net  Sat Jul  6 11:56:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat Jul  6 10:56:01 2002
Subject: [ expat-Patches-578161 ] Re: WFC: Entity Declared & Section 5.1
Message-ID: <E17QtmN-0006HH-00@usw-sf-web3.sourceforge.net>

Patches item #578161, was opened at 2002-07-06 13:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=578161&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Karl Waclawek (kwaclaw)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Re: WFC: Entity Declared & Section 5.1

Initial Comment:
This patch addresses three issues:
1) Bug #569461:
(conformance with OASIS test-suite) - partial fix
2) Bug #570263 (attr default & external PEs)
3) tab->blank conversion for xmlparse.c.

See the attached files PatchDesc.txt
for a description, and PatchImpl.txt
for an overview of the implementation.

The patch consists of the attached files 
expat.h (based on CVS rev. 1.26) and
xmlparse.c (based on CVS rev. 1.47).
For diff purposes I have attached an "untabified"
version of xmlparse.c rev. 1.47, since a diff against
the CVS version would be meaningless.

Karl

P.S: I have not attached this to one of the bugs,
since it is too large a patch.


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

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


From noreply@sourceforge.net  Sun Jul  7 09:23:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun Jul  7 08:23:03 2002
Subject: [ expat-Bugs-570263 ] Bug with attr defaults and external PE's
Message-ID: <E17RDrz-0003nk-00@usw-sf-web4.sourceforge.net>

Bugs item #570263, was opened at 2002-06-17 19:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=570263&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rolf Ade (pointsman)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Bug with attr defaults and external PE's

Initial Comment:
Take a look at this document:

<!DOCTYPE doc [
 <!ATTLIST doc a CDATA "D4A">
 <!ENTITY % x SYSTEM "x.ent">
 %x;
 <!ATTLIST doc b CDATA "D4B">
 ]>
<doc>Hello.</doc>


If you process this with expat 1.95.3 and without
processing the external entity %x; expat reports the
element doc with two attributes: a="D4A" b="D4B".

You could easily check this with the xmlwf tool, using
the -d option.

This is wrong. See the last paragraph of the XML rec
Second Editoin 5.1: "[...][T]hey must not process
entity declarations or attribute-list declarations
encountered after a reference to a parameter entity
that is not read, since the entity may have contained
overriding declarations."

As far as I see, this bug was already in 1.95.1, then
fixed in 1.95.2 and showed up again in 1.95.3

rolf


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-07 11:22

Message:
Logged In: YES 
user_id=290026

Patch # 578161 includes a fix for this bug.
Please test.

I have also attached a test document (files Rolf3.xml,
Rolf3_1.ent and Rolf3_2.ent) which test section 5.1 for
entity declarations. There is an entity reference %z; in
Rolf3_1.ent which needs to be skipped, since there is
no declaration for it, and this is not a WF error.
More details in the comment within Rolf3.xml.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-06-17 23:13

Message:
Logged In: YES 
user_id=290026

Yes, this is a bug, and was probably introduced by me.
Now I finally beging to understand why the dtd.complete flag
was used in such strange ways... :-(

So, I guess this one is for me,

Karl

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

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


From noreply@sourceforge.net  Sun Jul  7 09:33:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun Jul  7 08:33:06 2002
Subject: [ expat-Bugs-570263 ] Bug with attr defaults and external PE's
Message-ID: <E17RE1c-0007Z2-00@usw-sf-web1.sourceforge.net>

Bugs item #570263, was opened at 2002-06-17 19:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=570263&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rolf Ade (pointsman)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Bug with attr defaults and external PE's

Initial Comment:
Take a look at this document:

<!DOCTYPE doc [
 <!ATTLIST doc a CDATA "D4A">
 <!ENTITY % x SYSTEM "x.ent">
 %x;
 <!ATTLIST doc b CDATA "D4B">
 ]>
<doc>Hello.</doc>


If you process this with expat 1.95.3 and without
processing the external entity %x; expat reports the
element doc with two attributes: a="D4A" b="D4B".

You could easily check this with the xmlwf tool, using
the -d option.

This is wrong. See the last paragraph of the XML rec
Second Editoin 5.1: "[...][T]hey must not process
entity declarations or attribute-list declarations
encountered after a reference to a parameter entity
that is not read, since the entity may have contained
overriding declarations."

As far as I see, this bug was already in 1.95.1, then
fixed in 1.95.2 and showed up again in 1.95.3

rolf


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-07 11:32

Message:
Logged In: YES 
user_id=290026

Small correction:
The file Rolf3_2.ent is actually not needed, since it
won't be read by Expat, but I attached it anyway.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-07 11:22

Message:
Logged In: YES 
user_id=290026

Patch # 578161 includes a fix for this bug.
Please test.

I have also attached a test document (files Rolf3.xml,
Rolf3_1.ent and Rolf3_2.ent) which test section 5.1 for
entity declarations. There is an entity reference %z; in
Rolf3_1.ent which needs to be skipped, since there is
no declaration for it, and this is not a WF error.
More details in the comment within Rolf3.xml.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-06-17 23:13

Message:
Logged In: YES 
user_id=290026

Yes, this is a bug, and was probably introduced by me.
Now I finally beging to understand why the dtd.complete flag
was used in such strange ways... :-(

So, I guess this one is for me,

Karl

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

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


From noreply@sourceforge.net  Sun Jul  7 09:40:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun Jul  7 08:40:02 2002
Subject: [ expat-Bugs-569461 ] 1.95.3 and new OASIS xml test suite
Message-ID: <E17RE8M-0007Fr-00@usw-sf-web2.sourceforge.net>

Bugs item #569461, was opened at 2002-06-15 15:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=569461&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rolf Ade (pointsman)
Assigned to: Karl Waclawek (kwaclaw)
Summary: 1.95.3 and new OASIS xml test suite

Initial Comment:
I've tested expat-1.95.3 (with xmltok.c updated to rev.
1.17, becase of bug 566240, all other files are the
original 1.95.3) against the recently updated OASIS xml
test suite (XML 1.0 (Second Edition) errata 20020320,
W3C Conformance Test Suite 20020606), avaliable via
http://www.w3.org/XML/Test/ and found a few new
problems, that are not triggered by older versions of
this test suite.

As in previous reports, I checked all
not-wellformedness tests (should
all raise error) and all valid tests (should all pass)
of the
test-suites xmltest, ibm, sun and oasis with xmlwf -p.
Especially for the well-formedness tests, I have _not_
throughout checked if the error reason, reported by
expat is the expected error, but checked only
mechanical, if the test has raised an error, regardless
of the exact error reason. This method is clearly not
perfect, and this time we have an example, that
underlines this.

ibm/not-wf/P32/ibm32n09.xml

This is a new test, not included in previous versions.
Problem is, that the standalone document declaration
has the value "yes" and there is an external markup
declaration of an entity (other than amp, lt, gt, apos,
quot). xmlwf -p doesn't report an error. The not
well-formedness problem is, that standalone="yes"
means, that all informations needed to build the XML
infoset must be found in the document entity
(standalone="yes" doesn't mean, that the document must
not have an external subset or external PE's, only that
this external entities doesn't change - per attribute
defaults or as in this case, entity declarations -
change the info in the document entity. See the last
sentence of "Well-Formedness Constraint: Entity
Declared" (P68).


ibm/not-wf/P68/ibm68n06.xml

Same reason as the test befor. This test _was_ present
in previous versions of the test suite. But with the
previous version of the external subset of this test,
xmlwf claimed a "syntax error" error in the external
subset, which I plain can't understand (eventually an
other expat bug?), but is clearly not the expected
error. In the new version of the test suite, this
external subset now has an XML declaration with
explicite encoding (the older version had only an XML
declaration without encoding) and is accepted by expat.


xmltest/not-wf/not-sa/010.xml
xmltest/not-wf/not-sa/011.xml

This tests are new in this edition of the test suite.
Unfortunately, this both tests seems to be not
documented, either in the test files isself nor in the
documentation file xmlconf-20020606.htm. As far as I
see, this tests test "Validity Constraint: Proper
Declaration/PE Nesting" (P29).


xmltest/not-wf/not-sa/005.xml

This test raised error with previous expat versions,
but does not anymore due to the changes, discussed in
bug 548690. This is intentional, according to the
548690 discussion. This test is now listed under "XML
Documents with Optional Errors". The test suite
documentation says:

"Conforming XML 1.0 Processors are permitted to ignore
certain errors, or to report them at user option. In
this section of this test report are found descriptions
of test cases which fit into this category.

Processor behavior on such test cases does not affect
conformance to the XML 1.0 (Second Edition)
Recommendation, except as noted." 

So, according to this, it's OK, that expat doesn't
report an error for this case. Since both reporting
error and not reporting error are OK, it may be
debatably, which behavior is more convenient for the
expat user. (Karl: ;-))



sun/not-wf/not-sa03.xml

This is a new test in this edition of the test suite.
Unfortunately, this test seems not to be documented. As
far as I see, it tests the same as
xmltest/not-wf/not-sa/005.xml



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

ibm/not-wf/misc/432gewf.xml
sun/not-wf/uri01.xml

These are already discussed in the past.

Well, that's all.

rolf


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-07 11:39

Message:
Logged In: YES 
user_id=290026

Patch #587161 should fix some of the problems,
but I specifically made no attempt to fix the problems
Expat has with:
- xmltest/not-wf/not-sa/010.xml and
- xmltest/not-wf/not-sa/011.xml.

Reason: It turns out, after consulting with the mailing
list for the XML test suite, public-xml-testsuite@w3.org,
that these two violate WFC: PE Between Declarations.
There is no quick and easy fix for this in Expat,
and I would have to spend some time thinking about it,
which I don't have at the moment.

Karl


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-06-17 23:15

Message:
Logged In: YES 
user_id=290026

Assigned to me, but only for the three test cases
described in my last message.

Karl

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

Comment By: Rolf Ade (pointsman)
Date: 2002-06-17 19:21

Message:
Logged In: YES 
user_id=13222

Agreed

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-06-17 15:05

Message:
Logged In: YES 
user_id=290026

Given an improved understanding of section 4.1
in the XML spec, I will try to fix the following
test cases in the next Expat release:

ibm/not-wf/P32/ibm32n09.xml,
ibm/not-wf/P68/ibm68n06.xml and
sun/not-wf/not-sa03.xml 

In my opinion, the third one is not the same type as
xmltest/not-wf/not-sa/005.xml, but the same type
as the other two.

About the test cases
xmltest/not-wf/not-sa/010.xml and
xmltest/not-wf/not-sa/011.xml:

If they really check validity constraint P29, as Rolf
has suggested, then it is OK that Expat does not report
an error.

So, If I am successful, we would be left with only:
ibm/not-wf/misc/432gewf.xml and
sun/not-wf/uri01.xml,
conformance with which does not seem a 100% 
necessity, as previously discussed.

Karl









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

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


From noreply@sourceforge.net  Sun Jul  7 18:32:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun Jul  7 17:32:02 2002
Subject: [ expat-Patches-578161 ] Re: WFC: Entity Declared & Section 5.1
Message-ID: <E17RMRY-0002d7-00@usw-sf-web5.sourceforge.net>

Patches item #578161, was opened at 2002-07-06 13:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=578161&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Karl Waclawek (kwaclaw)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Re: WFC: Entity Declared & Section 5.1

Initial Comment:
This patch addresses three issues:
1) Bug #569461:
(conformance with OASIS test-suite) - partial fix
2) Bug #570263 (attr default & external PEs)
3) tab->blank conversion for xmlparse.c.

See the attached files PatchDesc.txt
for a description, and PatchImpl.txt
for an overview of the implementation.

The patch consists of the attached files 
expat.h (based on CVS rev. 1.26) and
xmlparse.c (based on CVS rev. 1.47).
For diff purposes I have attached an "untabified"
version of xmlparse.c rev. 1.47, since a diff against
the CVS version would be meaningless.

Karl

P.S: I have not attached this to one of the bugs,
since it is too large a patch.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-07 20:31

Message:
Logged In: YES 
user_id=290026

I forgot to mention that the behaviour of the 
skippedEntityHandler callback was modified,
to be in line with the SAX2 specs, but also for
logical reasons:

It makes not much sense to report skipped parameter
entities in declarations and skipped general entities in
attribute values, because such events would be
"out of sync" with the sequence of other callbacks.

Btw, this is an issue that did also come up when
discussing the internalEntityRefHandler feature request, i.e.
when considering the option of *not* expanding such entities.

In this case we were thinking about a special (optional)
marker character (similar to the NS separator). That approach
would also be applicable to the case of skipped entities.

Karl

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

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


From noreply@sourceforge.net  Mon Jul  8 11:49:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul  8 10:49:53 2002
Subject: [ expat-Patches-578161 ] Re: WFC: Entity Declared & Section 5.1
Message-ID: <E17RcK3-0007Za-00@usw-sf-web2.sourceforge.net>

Patches item #578161, was opened at 2002-07-06 13:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=578161&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Karl Waclawek (kwaclaw)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Re: WFC: Entity Declared & Section 5.1

Initial Comment:
This patch addresses three issues:
1) Bug #569461:
(conformance with OASIS test-suite) - partial fix
2) Bug #570263 (attr default & external PEs)
3) tab->blank conversion for xmlparse.c.

See the attached files PatchDesc.txt
for a description, and PatchImpl.txt
for an overview of the implementation.

The patch consists of the attached files 
expat.h (based on CVS rev. 1.26) and
xmlparse.c (based on CVS rev. 1.47).
For diff purposes I have attached an "untabified"
version of xmlparse.c rev. 1.47, since a diff against
the CVS version would be meaningless.

Karl

P.S: I have not attached this to one of the bugs,
since it is too large a patch.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-08 13:29

Message:
Logged In: YES 
user_id=290026

I ran a new shell script testing this patch against the
current version of the xml test suite available at:
http://www.w3.org/XML/Test/xmlts20020606.zip .

This new script adds the following functionality:
It tries to match the output files from the test suite
against those produced by xmlwf
(applying to valid test files only, of course).

It seems that basically the only differences found are,
that the canonical output in the test-suite includes
notation declarations, whereas xmlwf does not produce
them. Other than that, there is only one discrepancy
regarding ibm/valid/P02/ibm02v01.xml.

However, on the test-suite mailing list, it was reported
that the corresponding output file may be incorrect.
Check the archive at:
http://lists.w3.org/Archives/Public/public-xml-
testsuite/2002Jun/thread.html

Therefore it seems that the only mismatches the test
script found are due to the definition of "canonical"
output in xmlwf, which does not conform to the
w3 recommendation.

The script is attached as file test1.sh.
I was running it under Cygwin.
If you want to use it, you need to adjust the
definitions of $XMLWF and $OUTPUT for your
environment.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-07 20:31

Message:
Logged In: YES 
user_id=290026

I forgot to mention that the behaviour of the 
skippedEntityHandler callback was modified,
to be in line with the SAX2 specs, but also for
logical reasons:

It makes not much sense to report skipped parameter
entities in declarations and skipped general entities in
attribute values, because such events would be
"out of sync" with the sequence of other callbacks.

Btw, this is an issue that did also come up when
discussing the internalEntityRefHandler feature request, i.e.
when considering the option of *not* expanding such entities.

In this case we were thinking about a special (optional)
marker character (similar to the NS separator). That approach
would also be applicable to the case of skipped entities.

Karl

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

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


From noreply@sourceforge.net  Mon Jul  8 12:03:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul  8 11:03:34 2002
Subject: [ expat-Patches-566901 ] install (if building outside the sourcedir) fails
Message-ID: <E17RcqR-0001KP-00@usw-sf-web4.sourceforge.net>

Patches item #566901, was opened at 2002-06-10 11:30
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=566901&group_id=10127

Category: Build Control
Group: None
Status: Open
>Resolution: Accepted
Priority: 7
Submitted By: Gerrit Haase (siebenschlaefer)
>Assigned to: Gerrit Haase (siebenschlaefer)
Summary: install (if building outside the sourcedir) fails

Initial Comment:
1. It is not possible to build outside the sourcedir.
Starts with wrong paths and after fixing this I get 
problems because expat.h and the manfile were not 
found. e.g. error , please see below.
2. Calling autoconf gives this message:
    conftools/get-version.sh: not found


/usr/bin/install -c 
lib/.libs/libexpat.dll.a /var/www/htdocs/cywgin/ex
pat/test/expat-1.95.3/.inst/usr/lib/libexpat.dll.a
dlpath=`bash 2>&1 -c '. 
lib/.libs/lib/libexpat.lai;echo $dlname'`
 dldir=/var/www/htdocs/cywgin/expat/test/expat-
1.95.3/.inst/usr/lib/`dirname $dlpath`
dirname: too many arguments
Try `dirname --help' for more information.
make: *** [installlib] Error 1


Attached is the diff from my changes to Makefile.in 
to get it to install successfull outside the sourcedir.


Gerrit
-- 
=^..^=

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-08 14:02

Message:
Logged In: YES 
user_id=3066

Gerrit: I've tested the new version of the and it works for
me.  Please commit the changes.

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

Comment By: Gerrit Haase (siebenschlaefer)
Date: 2002-06-12 10:44

Message:
Logged In: YES 
user_id=76037

Hi David,

you wrote:
>Gerrit's patch almost works for me. However, I also had
>to change

>  INCLUDES = -Ilib -I.

>to

>  INCLUDES = -I$(srcdir)/lib -I.


you are right.  This is an oversight from me, since I have 
expat already installed in the standard locations I got no 
problems.  This needs to be fixed in my latest package 
which I offered for inclusion to the Cygwin netrelease.

>Moreover, I don't understand the need
>for the docdir macro.  There's no target that uses this, 
>AFAICT.

Yes, also true, this is only used for internal (Cygwin) 
use, we install docs into /usr/doc/${package-name},
I wanted to create the docdir from the make run, but 
never used it. (docs here are including license 
information and the README included in the expat 
source dist.)

I do this with my build script, no need to include it in 
the dist since expat doesn't install docs besides the 
manfile.


Many thanks for your patch review;)

Gerrit
-- 
=^..^=

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

Comment By: Gerrit Haase (siebenschlaefer)
Date: 2002-06-12 10:43

Message:
Logged In: YES 
user_id=76037

Hi David,

you wrote:
>Gerrit's patch almost works for me. However, I also had
>to change

>  INCLUDES = -Ilib -I.

>to

>  INCLUDES = -I$(srcdir)/lib -I.


you are right.  This is an oversight from me, since I have 
expat already installed in the standard locations I got no 
problems.  This needs to be fixed in my latest package 
which I offered for inclusion to the Cygwin netrelease.

>Moreover, I don't understand the need
>for the docdir macro.  There's no target that uses this, 
>AFAICT.

Yes, also true, this is only used for internal (Cygwin) 
use, we install docs into /usr/doc/${package-name},
I wanted to create the docdir from the make run, but 
never used it. (docs here are including license 
information and the README included in the expat 
source dist.)

I do this with my build script, no need to include it in 
the dist since expat doesn't install docs besides the 
manfile.


Many thanks for your patch review;)

Gerrit
-- 
=^..^=

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

Comment By: David Starks-Browning (davidsb)
Date: 2002-06-12 10:06

Message:
Logged In: YES 
user_id=561928

Yes, please do get "make" and "make install" working when building outside the source tree.
I also need it, and not for Cygwin. :-)

Gerrit's patch almost works for me. However, I also had to change

  INCLUDES = -Ilib -I.

to

  INCLUDES = -I$(srcdir)/lib -I.

Gerrit, if you didn't need this, then you probably compiled with whatever expat.h had been installed
in the default location (or as augmented by CPPFLAGS).

Moreover, I don't understand the need
for the docdir macro.  There's no target that uses this, AFAICT.

For the record, I had reported similar problems with 1.95.1 in bug #406262, but had not tracked expat
development since then.

Thanks everyone!

David

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

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


From noreply@sourceforge.net  Mon Jul  8 16:21:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul  8 15:21:02 2002
Subject: [ expat-Patches-578161 ] Re: WFC: Entity Declared & Section 5.1
Message-ID: <E17Rgre-0005td-00@usw-sf-web4.sourceforge.net>

Patches item #578161, was opened at 2002-07-06 13:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=578161&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Karl Waclawek (kwaclaw)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Re: WFC: Entity Declared & Section 5.1

Initial Comment:
This patch addresses three issues:
1) Bug #569461:
(conformance with OASIS test-suite) - partial fix
2) Bug #570263 (attr default & external PEs)
3) tab->blank conversion for xmlparse.c.

See the attached files PatchDesc.txt
for a description, and PatchImpl.txt
for an overview of the implementation.

The patch consists of the attached files 
expat.h (based on CVS rev. 1.26) and
xmlparse.c (based on CVS rev. 1.47).
For diff purposes I have attached an "untabified"
version of xmlparse.c rev. 1.47, since a diff against
the CVS version would be meaningless.

Karl

P.S: I have not attached this to one of the bugs,
since it is too large a patch.


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-08 18:20

Message:
Logged In: YES 
user_id=3066

API note:  XML_ERROR_ENTITY_DECLARED_IN_PE should be added
to the end of the XML_Error enum, otherwise code that uses
Expat needs to be re-compiled as well as re-linked for a new
version of the library.

Still reviewing all the changes; this is a pretty serious
patch!  Assigned to myself to finish reviewing.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-08 13:29

Message:
Logged In: YES 
user_id=290026

I ran a new shell script testing this patch against the
current version of the xml test suite available at:
http://www.w3.org/XML/Test/xmlts20020606.zip .

This new script adds the following functionality:
It tries to match the output files from the test suite
against those produced by xmlwf
(applying to valid test files only, of course).

It seems that basically the only differences found are,
that the canonical output in the test-suite includes
notation declarations, whereas xmlwf does not produce
them. Other than that, there is only one discrepancy
regarding ibm/valid/P02/ibm02v01.xml.

However, on the test-suite mailing list, it was reported
that the corresponding output file may be incorrect.
Check the archive at:
http://lists.w3.org/Archives/Public/public-xml-
testsuite/2002Jun/thread.html

Therefore it seems that the only mismatches the test
script found are due to the definition of "canonical"
output in xmlwf, which does not conform to the
w3 recommendation.

The script is attached as file test1.sh.
I was running it under Cygwin.
If you want to use it, you need to adjust the
definitions of $XMLWF and $OUTPUT for your
environment.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-07 20:31

Message:
Logged In: YES 
user_id=290026

I forgot to mention that the behaviour of the 
skippedEntityHandler callback was modified,
to be in line with the SAX2 specs, but also for
logical reasons:

It makes not much sense to report skipped parameter
entities in declarations and skipped general entities in
attribute values, because such events would be
"out of sync" with the sequence of other callbacks.

Btw, this is an issue that did also come up when
discussing the internalEntityRefHandler feature request, i.e.
when considering the option of *not* expanding such entities.

In this case we were thinking about a special (optional)
marker character (similar to the NS separator). That approach
would also be applicable to the case of skipped entities.

Karl

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

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


From Josh.Martin@abq.sc.philips.com  Mon Jul  8 16:21:05 2002
From: Josh.Martin@abq.sc.philips.com (Josh Martin)
Date: Mon Jul  8 15:21:05 2002
Subject: [Expat-discuss] help : how to use the expat-1.95.3
Message-ID: <200207082220.QAA14067@abqn42.abq.sc.philips.com>

Hi,

Okay, as far as I can see you seem to have several problems going on here.

First, expat is NOT a perl library/module, but a C library. To get it to work 
for perl you'd have to write a wrapper library for it, or use something like the 
XML::Parse module (which I know nothing about).

Second, it looks like the copy of gcc which "configure" is trying to run might 
be broken, and was probably built for a different machine. Do a "gcc -v" and 
"gcc -dumpmachine" and make sure that it is built for the machine you are using 
(do "uname -a").

Third, putting "/usr/ccs/bin" in front of your path is causing the make script 
to run the C compiler which came with your machine, which is only built to 
compile the kernal source, and is not capable of compiling most any other code 
correctly (except for bootstrapping type sources like the gcc distribution).  
You have to either buy the full ANSI C language compiler from HP (which is what 
that error message is referring to), or get a free compiler like gcc, which you 
seem to have.  You might also need to add "CC=gcc" along with the PATH 
declaration when you issue the "make" command.

Fourth, you need to run "configure" just once, not three times like you are 
doing.  You have to state all of the options that you want on that singe 
execution of "configure".

And lastly, the example piece of code you have written there is neither correct 
C code, nor is it correct perl code.

I'm sorry this probably doesn't help you do what you wanted to do, and I hope 
this information is clear enough, but I know I don't speak your language, and 
you still seem to be learning mine.  Good luck.

 - Josh Martin

> i am installed expat-1.95.3 in my sunOS5.8 but the
> path for expat-1.95.3/lib and expat-1.95.3/bin is not
> set.whenever i try to run my parser perl program is
> not at all Identifying the parser methods.
> 
> these are the septs i have followed.
> 1) down loaded expat-1.95.3 from sourceforge.net 
> 2) put into my home directory(/misc/home/john/)
> 3) gunzip and tar the .gz file(it's created a file
> expat-1.95.3)
> 4) ./configure -PREFIX=/misc/home/john/expat-1.95.3
> 5) ./configure CPPFLAGS=-DXML_UNICODE
> 6) ./configure CFLAGS="-g -O2 -fshort-wchar" PPFLAGS=-
>    DXML_UNICODE_WCHAR_T
> It's trowing error(<govind@tucson:>./configure
> CFLAGS="-g -O2 -fshort-wchar" PPFLAGS=-DXML_UNICO>
> 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... configure:
> error: C compiler cannot create executables)
> 
> 7) make buildlib
> 8) make installlib
> 9) PATH=/usr/ccs/bin:$PATH make
> throwing error(
> cc -g -O2 -Wall -Wmissing-prototypes
> -Wstrict-prototypes -fexceptions  -DXML_UNICODE -Ilib
> -I. -o xmlwf/xmlwf.o -c xmlwf/xmlwf.c
> /usr/ucb/cc:  language optional software package not
> installed
> *** Error code 1
> make: Fatal error: Command failed for target
> `xmlwf/xmlwf.o'
> )
> 10)  LD_LIBRARY_PATH = {$LD_LIBRARY_PATH
> }:/misc/home/john/expat-1.95.3
> 
> After this if i run any perl file having lib function
> like
> 
> XML_Parser
> XML_LChar *
> XML_ExpatVersion();
> 
> throwing error 
> (
> syntax error at test.pl line 3, near "*
> XML_ExpatVersion("
> Execution of test.pl aborted due to compilation
> errors.
> )
> 
> Please advice what i want to do get this work well
> 
> 
> govind
>  
> ________________________________________________________________________
> Want to sell your car? advertise on Yahoo Autos Classifieds. It's Free!!
>        visit http://in.autos.yahoo.com
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Expat-discuss mailing list
> Expat-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/expat-discuss



From noreply@sourceforge.net  Mon Jul  8 17:15:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul  8 16:15:02 2002
Subject: [ expat-Patches-578161 ] Re: WFC: Entity Declared & Section 5.1
Message-ID: <E17RhiZ-0004Ho-00@usw-sf-web2.sourceforge.net>

Patches item #578161, was opened at 2002-07-06 13:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=578161&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Karl Waclawek (kwaclaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Re: WFC: Entity Declared & Section 5.1

Initial Comment:
This patch addresses three issues:
1) Bug #569461:
(conformance with OASIS test-suite) - partial fix
2) Bug #570263 (attr default & external PEs)
3) tab->blank conversion for xmlparse.c.

See the attached files PatchDesc.txt
for a description, and PatchImpl.txt
for an overview of the implementation.

The patch consists of the attached files 
expat.h (based on CVS rev. 1.26) and
xmlparse.c (based on CVS rev. 1.47).
For diff purposes I have attached an "untabified"
version of xmlparse.c rev. 1.47, since a diff against
the CVS version would be meaningless.

Karl

P.S: I have not attached this to one of the bugs,
since it is too large a patch.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-08 19:14

Message:
Logged In: YES 
user_id=290026

Fred, are you going to move 
XML_ERROR_ENTITY_DECLARED_IN_PE yourself,
or do you want me to do it?

Also, I attached an improved shellscript, provided
by Rolf Ade, since the one I wrote wouldn't run
on Unix witout some extra effort (Obviously, I never wrote
a shell script before :-) )

Karl



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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-08 18:20

Message:
Logged In: YES 
user_id=3066

API note:  XML_ERROR_ENTITY_DECLARED_IN_PE should be added
to the end of the XML_Error enum, otherwise code that uses
Expat needs to be re-compiled as well as re-linked for a new
version of the library.

Still reviewing all the changes; this is a pretty serious
patch!  Assigned to myself to finish reviewing.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-08 13:29

Message:
Logged In: YES 
user_id=290026

I ran a new shell script testing this patch against the
current version of the xml test suite available at:
http://www.w3.org/XML/Test/xmlts20020606.zip .

This new script adds the following functionality:
It tries to match the output files from the test suite
against those produced by xmlwf
(applying to valid test files only, of course).

It seems that basically the only differences found are,
that the canonical output in the test-suite includes
notation declarations, whereas xmlwf does not produce
them. Other than that, there is only one discrepancy
regarding ibm/valid/P02/ibm02v01.xml.

However, on the test-suite mailing list, it was reported
that the corresponding output file may be incorrect.
Check the archive at:
http://lists.w3.org/Archives/Public/public-xml-
testsuite/2002Jun/thread.html

Therefore it seems that the only mismatches the test
script found are due to the definition of "canonical"
output in xmlwf, which does not conform to the
w3 recommendation.

The script is attached as file test1.sh.
I was running it under Cygwin.
If you want to use it, you need to adjust the
definitions of $XMLWF and $OUTPUT for your
environment.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-07 20:31

Message:
Logged In: YES 
user_id=290026

I forgot to mention that the behaviour of the 
skippedEntityHandler callback was modified,
to be in line with the SAX2 specs, but also for
logical reasons:

It makes not much sense to report skipped parameter
entities in declarations and skipped general entities in
attribute values, because such events would be
"out of sync" with the sequence of other callbacks.

Btw, this is an issue that did also come up when
discussing the internalEntityRefHandler feature request, i.e.
when considering the option of *not* expanding such entities.

In this case we were thinking about a special (optional)
marker character (similar to the NS separator). That approach
would also be applicable to the case of skipped entities.

Karl

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

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


From noreply@sourceforge.net  Mon Jul  8 20:51:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul  8 19:51:01 2002
Subject: [ expat-Patches-578161 ] Re: WFC: Entity Declared & Section 5.1
Message-ID: <E17Rl4p-0006TB-00@usw-sf-web2.sourceforge.net>

Patches item #578161, was opened at 2002-07-06 13:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=578161&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Karl Waclawek (kwaclaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Re: WFC: Entity Declared & Section 5.1

Initial Comment:
This patch addresses three issues:
1) Bug #569461:
(conformance with OASIS test-suite) - partial fix
2) Bug #570263 (attr default & external PEs)
3) tab->blank conversion for xmlparse.c.

See the attached files PatchDesc.txt
for a description, and PatchImpl.txt
for an overview of the implementation.

The patch consists of the attached files 
expat.h (based on CVS rev. 1.26) and
xmlparse.c (based on CVS rev. 1.47).
For diff purposes I have attached an "untabified"
version of xmlparse.c rev. 1.47, since a diff against
the CVS version would be meaningless.

Karl

P.S: I have not attached this to one of the bugs,
since it is too large a patch.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-08 22:50

Message:
Logged In: YES 
user_id=290026

OK, 
hopefully this time the script is really clean of any
DOS linebreaks. Attached as test2.sh.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-08 19:14

Message:
Logged In: YES 
user_id=290026

Fred, are you going to move 
XML_ERROR_ENTITY_DECLARED_IN_PE yourself,
or do you want me to do it?

Also, I attached an improved shellscript, provided
by Rolf Ade, since the one I wrote wouldn't run
on Unix witout some extra effort (Obviously, I never wrote
a shell script before :-) )

Karl



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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-08 18:20

Message:
Logged In: YES 
user_id=3066

API note:  XML_ERROR_ENTITY_DECLARED_IN_PE should be added
to the end of the XML_Error enum, otherwise code that uses
Expat needs to be re-compiled as well as re-linked for a new
version of the library.

Still reviewing all the changes; this is a pretty serious
patch!  Assigned to myself to finish reviewing.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-08 13:29

Message:
Logged In: YES 
user_id=290026

I ran a new shell script testing this patch against the
current version of the xml test suite available at:
http://www.w3.org/XML/Test/xmlts20020606.zip .

This new script adds the following functionality:
It tries to match the output files from the test suite
against those produced by xmlwf
(applying to valid test files only, of course).

It seems that basically the only differences found are,
that the canonical output in the test-suite includes
notation declarations, whereas xmlwf does not produce
them. Other than that, there is only one discrepancy
regarding ibm/valid/P02/ibm02v01.xml.

However, on the test-suite mailing list, it was reported
that the corresponding output file may be incorrect.
Check the archive at:
http://lists.w3.org/Archives/Public/public-xml-
testsuite/2002Jun/thread.html

Therefore it seems that the only mismatches the test
script found are due to the definition of "canonical"
output in xmlwf, which does not conform to the
w3 recommendation.

The script is attached as file test1.sh.
I was running it under Cygwin.
If you want to use it, you need to adjust the
definitions of $XMLWF and $OUTPUT for your
environment.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-07 20:31

Message:
Logged In: YES 
user_id=290026

I forgot to mention that the behaviour of the 
skippedEntityHandler callback was modified,
to be in line with the SAX2 specs, but also for
logical reasons:

It makes not much sense to report skipped parameter
entities in declarations and skipped general entities in
attribute values, because such events would be
"out of sync" with the sequence of other callbacks.

Btw, this is an issue that did also come up when
discussing the internalEntityRefHandler feature request, i.e.
when considering the option of *not* expanding such entities.

In this case we were thinking about a special (optional)
marker character (similar to the NS separator). That approach
would also be applicable to the case of skipped entities.

Karl

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

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


From noreply@sourceforge.net  Tue Jul  9 09:38:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul  9 08:38:08 2002
Subject: [ expat-Bugs-579144 ] DLLs are not drop-in compatible
Message-ID: <E17Rx3k-0003E7-00@usw-sf-web4.sourceforge.net>

Bugs item #579144, was opened at 2002-07-09 11:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=579144&group_id=10127

Category: Build control
Group: Feature Request
Status: Open
Resolution: None
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: DLLs are not drop-in compatible

Initial Comment:
For Windows DLLs, Expat should be using a .DEF file
instead of __declspec(dllexport) to control the export
of symbols.  Using a .DEF file allows symbols to have
the same ordinal position in the export table of the
DLL regardless of accidents of the compiler's
organization of the table, allowing newer DLLs to
replace older DLLs by simply dropping them in place.

More information on DLL exports:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_core_determine_which_exporting_method_to_use.asp

This feature request is based on an email conversation
with Nick Lehman, following up from:
http://sourceforge.net/mailarchive/message.php?msg_id=1783043


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

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


From noreply@sourceforge.net  Tue Jul  9 11:28:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul  9 10:28:07 2002
Subject: [ expat-Patches-576406 ] [ 576396 ] expat 1.95.3 on aix 4.3.3
Message-ID: <E17Rylz-000225-00@usw-sf-web1.sourceforge.net>

Patches item #576406, was opened at 2002-07-02 10:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=576406&group_id=10127

Category: Build Control
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: José AUGUSTE-ETIENNE (joseae)
Assigned to: Greg Stein (gstein)
Summary: [ 576396 ] expat 1.95.3 on aix 4.3.3

Initial Comment:
[ 576396 ] expat 1.95.3 fails to build on aix 4.3.3

this patch modifies 'configure' by passing $output_objdir
instead of $objdir to AR

I hope there won't be line wrapping problems,
since upload/attachements don't seem to work

José

--- begin of patch ---
--- configure.orig	2002-07-02 
09:33:45.000000000 -0300
+++ configure	2002-07-02 
09:34:44.000000000 -0300
@@ -4881,7 +4881,7 @@
         allow_undefined_flag='${wl}-berok'
         # This is a bit strange, but is similar to how AIX 
traditionally builds
         # it's shared libraries.
-        archive_expsym_cmds="\ $shared_flag"' -o 
$output_objdir/$soname $libobjs $deplibs $compiler_flags 
${allow_undefined_flag} '"\$no_entry_flag \
$exp_sym_flag:\"' ~$AR -crlo $objdir/
$libname$release.a $objdir/$soname'
+        archive_expsym_cmds="\ $shared_flag"' -o 
$output_objdir/$soname $libobjs $deplibs $compiler_flags 
${allow_undefined_flag} '"\$no_entry_flag \
$exp_sym_flag:\"' ~$AR -crlo 
$output_objdir/$libname$release.a $output_objdir/
$soname'
       fi
     fi
     ;;
--- end of patch ---

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 13:27

Message:
Logged In: YES 
user_id=3066

Closing this and the related bug report as "Won't fix". 
This definately appears to be a bug in autoconf.  I've
emailed a bug report to bug-autoconf@gnu.org, but I don't
see any way to refer to the autoconf bugs database; the one
link to it I found was stale.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-02 11:30

Message:
Logged In: YES 
user_id=3066

"configure" is a generated file; "configure.in" is where
changes need to be made.  Unfortunately, this doesn't appear
to have a simple mapping from the configure.in file.

I wonder if this is a problem with autoconf not knowing
enough about AIX?

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

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


From noreply@sourceforge.net  Tue Jul  9 11:29:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul  9 10:29:04 2002
Subject: [ expat-Bugs-576396 ] expat 1.95.3 fails to build on aix 4.3.3
Message-ID: <E17Ryml-0004qf-00@usw-sf-web4.sourceforge.net>

Bugs item #576396, was opened at 2002-07-02 10:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=576396&group_id=10127

Category: Build control
>Group: Third-party Bug
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: expat 1.95.3 fails to build on aix 4.3.3

Initial Comment:
Hi everybody,

when attempting to build expat 1.95.3 on aix 4.3.3,
i had the following error running 'make'

/bin/sh ./libtool --silent --mode=compile cc -g   -Ilib -I. -o 
lib/xmlparse.lo -
c lib/xmlparse.c
/bin/sh ./libtool --silent --mode=compile cc -g   -Ilib -I. -o 
lib/xmltok.lo -c
lib/xmltok.c
/bin/sh ./libtool --silent --mode=compile cc -g   -Ilib -I. -o 
lib/xmlrole.lo -c
 lib/xmlrole.c
/bin/sh ./libtool --silent --mode=link cc -g   -Ilib -I. -no-
undefined -version-
info 2:0:2 -rpath /usr/test/lib  -o lib/libexpat.la 
lib/xmlparse.lo lib/xmltok.l
o lib/xmlrole.lo
ar: No such file or directory
ar: 0707-113 The fopen system call failed on 
file .libs/libexpat.a.
make: *** [lib/libexpat.la] Erreur 1

I searched the web and found a similar error with a 
solution described in

http://www.freetype.org/pipermail/devel/2002-
March/003045.html

<quote>
The problem was the AR was being passed $objdir, when 
it should be $output_objdir. The former is a relative path, 
and we need an absolute path.
</quote>

It' a 'configure' issue
I tried it and it works !
I also succeeded to build perl module XML::Parser 2-31
:-)

I've sent the patch as an attachment

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 13:28

Message:
Logged In: YES 
user_id=3066

Closing this and the related patch report as "Won't fix". 
This definately appears to be a bug in autoconf.  I've
emailed a bug report to bug-autoconf@gnu.org, but I don't
see any way to refer to the autoconf bugs database; the one
link to it I found was stale.

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

Comment By: José AUGUSTE-ETIENNE (joseae)
Date: 2002-07-02 10:53

Message:
Logged In: YES 
user_id=571932

The attachment did not work the first time.
See the attachment for Patch #  576406 on "Patches" page

José

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

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


From noreply@sourceforge.net  Tue Jul  9 11:34:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul  9 10:34:03 2002
Subject: [ expat-Bugs-576396 ] expat 1.95.3 fails to build on aix 4.3.3
Message-ID: <E17Ryrk-00041K-00@usw-sf-web2.sourceforge.net>

Bugs item #576396, was opened at 2002-07-02 10:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=576396&group_id=10127

Category: Build control
Group: Third-party Bug
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: expat 1.95.3 fails to build on aix 4.3.3

Initial Comment:
Hi everybody,

when attempting to build expat 1.95.3 on aix 4.3.3,
i had the following error running 'make'

/bin/sh ./libtool --silent --mode=compile cc -g   -Ilib -I. -o 
lib/xmlparse.lo -
c lib/xmlparse.c
/bin/sh ./libtool --silent --mode=compile cc -g   -Ilib -I. -o 
lib/xmltok.lo -c
lib/xmltok.c
/bin/sh ./libtool --silent --mode=compile cc -g   -Ilib -I. -o 
lib/xmlrole.lo -c
 lib/xmlrole.c
/bin/sh ./libtool --silent --mode=link cc -g   -Ilib -I. -no-
undefined -version-
info 2:0:2 -rpath /usr/test/lib  -o lib/libexpat.la 
lib/xmlparse.lo lib/xmltok.l
o lib/xmlrole.lo
ar: No such file or directory
ar: 0707-113 The fopen system call failed on 
file .libs/libexpat.a.
make: *** [lib/libexpat.la] Erreur 1

I searched the web and found a similar error with a 
solution described in

http://www.freetype.org/pipermail/devel/2002-
March/003045.html

<quote>
The problem was the AR was being passed $objdir, when 
it should be $output_objdir. The former is a relative path, 
and we need an absolute path.
</quote>

It' a 'configure' issue
I tried it and it works !
I also succeeded to build perl module XML::Parser 2-31
:-)

I've sent the patch as an attachment

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 13:33

Message:
Logged In: YES 
user_id=3066

Found a link to the bug report I filed:
http://mail.gnu.org/pipermail/bug-autoconf/2002-July/001693.html

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 13:28

Message:
Logged In: YES 
user_id=3066

Closing this and the related patch report as "Won't fix". 
This definately appears to be a bug in autoconf.  I've
emailed a bug report to bug-autoconf@gnu.org, but I don't
see any way to refer to the autoconf bugs database; the one
link to it I found was stale.

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

Comment By: José AUGUSTE-ETIENNE (joseae)
Date: 2002-07-02 10:53

Message:
Logged In: YES 
user_id=571932

The attachment did not work the first time.
See the attachment for Patch #  576406 on "Patches" page

José

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

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


From noreply@sourceforge.net  Tue Jul  9 11:35:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul  9 10:35:02 2002
Subject: [ expat-Patches-576406 ] [ 576396 ] expat 1.95.3 on aix 4.3.3
Message-ID: <E17Rysf-0002AJ-00@usw-sf-web1.sourceforge.net>

Patches item #576406, was opened at 2002-07-02 10:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=576406&group_id=10127

Category: Build Control
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: José AUGUSTE-ETIENNE (joseae)
Assigned to: Greg Stein (gstein)
Summary: [ 576396 ] expat 1.95.3 on aix 4.3.3

Initial Comment:
[ 576396 ] expat 1.95.3 fails to build on aix 4.3.3

this patch modifies 'configure' by passing $output_objdir
instead of $objdir to AR

I hope there won't be line wrapping problems,
since upload/attachements don't seem to work

José

--- begin of patch ---
--- configure.orig	2002-07-02 
09:33:45.000000000 -0300
+++ configure	2002-07-02 
09:34:44.000000000 -0300
@@ -4881,7 +4881,7 @@
         allow_undefined_flag='${wl}-berok'
         # This is a bit strange, but is similar to how AIX 
traditionally builds
         # it's shared libraries.
-        archive_expsym_cmds="\ $shared_flag"' -o 
$output_objdir/$soname $libobjs $deplibs $compiler_flags 
${allow_undefined_flag} '"\$no_entry_flag \
$exp_sym_flag:\"' ~$AR -crlo $objdir/
$libname$release.a $objdir/$soname'
+        archive_expsym_cmds="\ $shared_flag"' -o 
$output_objdir/$soname $libobjs $deplibs $compiler_flags 
${allow_undefined_flag} '"\$no_entry_flag \
$exp_sym_flag:\"' ~$AR -crlo 
$output_objdir/$libname$release.a $output_objdir/
$soname'
       fi
     fi
     ;;
--- end of patch ---

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 13:34

Message:
Logged In: YES 
user_id=3066

Found a link to the bug report I filed:
http://mail.gnu.org/pipermail/bug-autoconf/2002-July/001693.html

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 13:27

Message:
Logged In: YES 
user_id=3066

Closing this and the related bug report as "Won't fix". 
This definately appears to be a bug in autoconf.  I've
emailed a bug report to bug-autoconf@gnu.org, but I don't
see any way to refer to the autoconf bugs database; the one
link to it I found was stale.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-02 11:30

Message:
Logged In: YES 
user_id=3066

"configure" is a generated file; "configure.in" is where
changes need to be made.  Unfortunately, this doesn't appear
to have a simple mapping from the configure.in file.

I wonder if this is a problem with autoconf not knowing
enough about AIX?

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

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


From noreply@sourceforge.net  Tue Jul  9 11:48:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul  9 10:48:04 2002
Subject: [ expat-Bugs-579196 ] Memory corruption with non-ASCII names
Message-ID: <E17Rz5O-0002c9-00@usw-sf-web1.sourceforge.net>

Bugs item #579196, was opened at 2002-07-09 13:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=579196&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Karl Waclawek (kwaclaw)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Memory corruption with non-ASCII names

Initial Comment:
I ran into a problem with Expat overwriting my
aplication memory. This happens when the content
model in an element declaration contains names
that are non-ASCII (e.g. Japanese).

This bug is hard to find, because it will not 
always bite.

I could trace this down to the following section
in the function doProlog, under switch case
XML_ROLE_CONTENT_ELEMENT_PLUS:
...
        el = getElementType(parser, enc, s, nxt);
        if (!el)
          return XML_ERROR_NO_MEMORY;
        dtd.scaffold[myindex].name = el->name;
        dtd.contentStringLen +=  nxt - s + 1;
...
dtd.contentStringLen is supposed to be incremented
by the length of el->name. However, for non-ASCII
names, the input length, nxt - s + 1, is not the 
same as the encoded length. The function 
poolStoreString within getElementType encodes the 
name from the input encoding to the working 
encoding of Expat (UTF-8 or UTF-16).

Specifically, in my test case, using a DTD encoded
in UTF-16BE and a working encoding of UTF-8, this
problem manifested itself in my app crashing badly.

Therefore I suggest this fix:
...
        const XML_Char *name;
        int nameLen;
...
        el = getElementType(parser, enc, s, nxt);
        if (!el)
          return XML_ERROR_NO_MEMORY;
        name = el->name;
        dtd.scaffold[myindex].name = name;
        nameLen = 0;
        for (; name[nameLen++]; );
        dtd.contentStringLen +=  nameLen;
...

Karl


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

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


From noreply@sourceforge.net  Tue Jul  9 12:09:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul  9 11:09:05 2002
Subject: [ expat-Bugs-579196 ] Memory corruption with non-ASCII names
Message-ID: <E17RzQ3-0005h4-00@usw-sf-web4.sourceforge.net>

Bugs item #579196, was opened at 2002-07-09 13:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=579196&group_id=10127

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 6
Submitted By: Karl Waclawek (kwaclaw)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Memory corruption with non-ASCII names

Initial Comment:
I ran into a problem with Expat overwriting my
aplication memory. This happens when the content
model in an element declaration contains names
that are non-ASCII (e.g. Japanese).

This bug is hard to find, because it will not 
always bite.

I could trace this down to the following section
in the function doProlog, under switch case
XML_ROLE_CONTENT_ELEMENT_PLUS:
...
        el = getElementType(parser, enc, s, nxt);
        if (!el)
          return XML_ERROR_NO_MEMORY;
        dtd.scaffold[myindex].name = el->name;
        dtd.contentStringLen +=  nxt - s + 1;
...
dtd.contentStringLen is supposed to be incremented
by the length of el->name. However, for non-ASCII
names, the input length, nxt - s + 1, is not the 
same as the encoded length. The function 
poolStoreString within getElementType encodes the 
name from the input encoding to the working 
encoding of Expat (UTF-8 or UTF-16).

Specifically, in my test case, using a DTD encoded
in UTF-16BE and a working encoding of UTF-8, this
problem manifested itself in my app crashing badly.

Therefore I suggest this fix:
...
        const XML_Char *name;
        int nameLen;
...
        el = getElementType(parser, enc, s, nxt);
        if (!el)
          return XML_ERROR_NO_MEMORY;
        name = el->name;
        dtd.scaffold[myindex].name = name;
        nameLen = 0;
        for (; name[nameLen++]; );
        dtd.contentStringLen +=  nameLen;
...

Karl


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 14:08

Message:
Logged In: YES 
user_id=3066

I like this change; feel free to check it in and close the bug.

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

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


From noreply@sourceforge.net  Tue Jul  9 14:26:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul  9 13:26:02 2002
Subject: [ expat-Patches-578161 ] Re: WFC: Entity Declared & Section 5.1
Message-ID: <E17S1Xg-0008En-00@usw-sf-web4.sourceforge.net>

Patches item #578161, was opened at 2002-07-06 13:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=578161&group_id=10127

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 7
Submitted By: Karl Waclawek (kwaclaw)
>Assigned to: Karl Waclawek (kwaclaw)
Summary: Re: WFC: Entity Declared & Section 5.1

Initial Comment:
This patch addresses three issues:
1) Bug #569461:
(conformance with OASIS test-suite) - partial fix
2) Bug #570263 (attr default & external PEs)
3) tab->blank conversion for xmlparse.c.

See the attached files PatchDesc.txt
for a description, and PatchImpl.txt
for an overview of the implementation.

The patch consists of the attached files 
expat.h (based on CVS rev. 1.26) and
xmlparse.c (based on CVS rev. 1.47).
For diff purposes I have attached an "untabified"
version of xmlparse.c rev. 1.47, since a diff against
the CVS version would be meaningless.

Karl

P.S: I have not attached this to one of the bugs,
since it is too large a patch.


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 16:25

Message:
Logged In: YES 
user_id=3066

Per email with Karl, I've checked in a de-tabified version
of xmlparse.c, and he's going to follow with the checkin of
this patch, which I'm assigning back to him as accepted.

Karl, can you add a brief entry to Changes summarizing the
changes relating to PE and skipped entity handling?

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-08 22:50

Message:
Logged In: YES 
user_id=290026

OK, 
hopefully this time the script is really clean of any
DOS linebreaks. Attached as test2.sh.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-08 19:14

Message:
Logged In: YES 
user_id=290026

Fred, are you going to move 
XML_ERROR_ENTITY_DECLARED_IN_PE yourself,
or do you want me to do it?

Also, I attached an improved shellscript, provided
by Rolf Ade, since the one I wrote wouldn't run
on Unix witout some extra effort (Obviously, I never wrote
a shell script before :-) )

Karl



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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-08 18:20

Message:
Logged In: YES 
user_id=3066

API note:  XML_ERROR_ENTITY_DECLARED_IN_PE should be added
to the end of the XML_Error enum, otherwise code that uses
Expat needs to be re-compiled as well as re-linked for a new
version of the library.

Still reviewing all the changes; this is a pretty serious
patch!  Assigned to myself to finish reviewing.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-08 13:29

Message:
Logged In: YES 
user_id=290026

I ran a new shell script testing this patch against the
current version of the xml test suite available at:
http://www.w3.org/XML/Test/xmlts20020606.zip .

This new script adds the following functionality:
It tries to match the output files from the test suite
against those produced by xmlwf
(applying to valid test files only, of course).

It seems that basically the only differences found are,
that the canonical output in the test-suite includes
notation declarations, whereas xmlwf does not produce
them. Other than that, there is only one discrepancy
regarding ibm/valid/P02/ibm02v01.xml.

However, on the test-suite mailing list, it was reported
that the corresponding output file may be incorrect.
Check the archive at:
http://lists.w3.org/Archives/Public/public-xml-
testsuite/2002Jun/thread.html

Therefore it seems that the only mismatches the test
script found are due to the definition of "canonical"
output in xmlwf, which does not conform to the
w3 recommendation.

The script is attached as file test1.sh.
I was running it under Cygwin.
If you want to use it, you need to adjust the
definitions of $XMLWF and $OUTPUT for your
environment.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-07 20:31

Message:
Logged In: YES 
user_id=290026

I forgot to mention that the behaviour of the 
skippedEntityHandler callback was modified,
to be in line with the SAX2 specs, but also for
logical reasons:

It makes not much sense to report skipped parameter
entities in declarations and skipped general entities in
attribute values, because such events would be
"out of sync" with the sequence of other callbacks.

Btw, this is an issue that did also come up when
discussing the internalEntityRefHandler feature request, i.e.
when considering the option of *not* expanding such entities.

In this case we were thinking about a special (optional)
marker character (similar to the NS separator). That approach
would also be applicable to the case of skipped entities.

Karl

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

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


From noreply@sourceforge.net  Tue Jul  9 14:32:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul  9 13:32:05 2002
Subject: [ expat-Patches-538032 ] Borland Win32 project & makefiles
Message-ID: <E17S1eP-0008OD-00@usw-sf-web4.sourceforge.net>

Patches item #538032, was opened at 2002-04-01 16:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=538032&group_id=10127

>Category: Build Control
>Group: Feature Request
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Patrick McConnell (pmcconnell)
Assigned to: Nobody/Anonymous (nobody)
Summary: Borland Win32 project & makefiles

Initial Comment:
Borland C++ Builder project file and make file for the 
command line compiler to build expat.dll

Unzip the patch from the directory above expat, then 
read the README.borland file for instructions.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 16:31

Message:
Logged In: YES 
user_id=3066

Closing due to non-responsiveness of the reporter and
generally not being able to bring this up to date.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 18:39

Message:
Logged In: YES 
user_id=3066

Well, I won't be able to install the C++ Builder demo on my Win2K 
system since I don't have enough space on my system disk.  ;-(

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 00:04

Message:
Logged In: YES 
user_id=3066

Does this need to be updated to reflect the header name change from 
"config.h" to "expat_config.h"?

I don't think I'll have time to look at 
this before 1.95.3; is this just a few additional files or do other files need 
changing?  I'll try to install the recent C++ Builder demo to try this out.

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

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


From noreply@sourceforge.net  Tue Jul  9 14:34:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul  9 13:34:07 2002
Subject: [ expat-Patches-566827 ] expat-1.95.3 does no with .dll on cygwin
Message-ID: <E17S1fo-0006Fe-00@usw-sf-web3.sourceforge.net>

Patches item #566827, was opened at 2002-06-10 09:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=566827&group_id=10127

Category: Build Control
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gerrit Haase (siebenschlaefer)
Assigned to: Gerrit Haase (siebenschlaefer)
Summary: expat-1.95.3 does no with .dll on cygwin

Initial Comment:
libtool-1.4 fails to build a shared version on 
Cygwin.  I've not tested it, but it should work with 
libtool-1.4.2 which is the latest release of libtool.

Gerrit
-- 
=^..^=

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 16:33

Message:
Logged In: YES 
user_id=3066

Expat 1.95.4 will be packaged using libtool 1.4.2.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-12 15:53

Message:
Logged In: YES 
user_id=3066

Gerrit, this is yours now!

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

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


From noreply@sourceforge.net  Tue Jul  9 14:53:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul  9 13:53:13 2002
Subject: [ expat-Bugs-570903 ] Remove tabs in sources
Message-ID: <E17S1yH-0006KE-00@usw-sf-web1.sourceforge.net>

Bugs item #570903, was opened at 2002-06-18 22:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=570903&group_id=10127

Category: None
Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Remove tabs in sources

Initial Comment:
All hard tabs should be removed from the source files.
This is a release requirement for Expat 1.95.4; the
changes will be made while preparing for the final release.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 16:52

Message:
Logged In: YES 
user_id=3066

lib/xmlparse.c has now been updated.  This task is complete.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-01 17:08

Message:
Logged In: YES 
user_id=3066

Almost complete; only lib/xmlparse.c remains to be done. 
Waiting for other developers to finish checking in
outstanding patches.

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

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


From noreply@sourceforge.net  Tue Jul  9 14:55:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul  9 13:55:02 2002
Subject: [ expat-Bugs-579196 ] Memory corruption with non-ASCII names
Message-ID: <E17S1zk-0006cp-00@usw-sf-web3.sourceforge.net>

Bugs item #579196, was opened at 2002-07-09 13:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=579196&group_id=10127

Category: None
Group: None
>Status: Closed
Resolution: Accepted
Priority: 6
Submitted By: Karl Waclawek (kwaclaw)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Memory corruption with non-ASCII names

Initial Comment:
I ran into a problem with Expat overwriting my
aplication memory. This happens when the content
model in an element declaration contains names
that are non-ASCII (e.g. Japanese).

This bug is hard to find, because it will not 
always bite.

I could trace this down to the following section
in the function doProlog, under switch case
XML_ROLE_CONTENT_ELEMENT_PLUS:
...
        el = getElementType(parser, enc, s, nxt);
        if (!el)
          return XML_ERROR_NO_MEMORY;
        dtd.scaffold[myindex].name = el->name;
        dtd.contentStringLen +=  nxt - s + 1;
...
dtd.contentStringLen is supposed to be incremented
by the length of el->name. However, for non-ASCII
names, the input length, nxt - s + 1, is not the 
same as the encoded length. The function 
poolStoreString within getElementType encodes the 
name from the input encoding to the working 
encoding of Expat (UTF-8 or UTF-16).

Specifically, in my test case, using a DTD encoded
in UTF-16BE and a working encoding of UTF-8, this
problem manifested itself in my app crashing badly.

Therefore I suggest this fix:
...
        const XML_Char *name;
        int nameLen;
...
        el = getElementType(parser, enc, s, nxt);
        if (!el)
          return XML_ERROR_NO_MEMORY;
        name = el->name;
        dtd.scaffold[myindex].name = name;
        nameLen = 0;
        for (; name[nameLen++]; );
        dtd.contentStringLen +=  nameLen;
...

Karl


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 16:54

Message:
Logged In: YES 
user_id=3066

Karl checked this in as lib/xmlparse.c revision 1.49.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 14:08

Message:
Logged In: YES 
user_id=3066

I like this change; feel free to check it in and close the bug.

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

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


From noreply@sourceforge.net  Tue Jul  9 15:19:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul  9 14:19:13 2002
Subject: [ expat-Bugs-478332 ] infinite loop if input line to long
Message-ID: <E17S2Nl-0003Ao-00@usw-sf-web5.sourceforge.net>

Bugs item #478332, was opened at 2001-11-05 10:29
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=478332&group_id=10127

Category: None
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: infinite loop if input line to long

Initial Comment:
In the main parser loop, the buffer that receives the 
input line is set to 1024 byte. If the line is longer 
than 1024 byte, the "XML_Parse" function is called and 
returns without parsing with the return value 
XML_NO_ERROR. The next "getLine" call to the input 
stream should get the next chunk of the input line. 
This second call to the input stream fails, because 
the output parameter "len" is set to "0" but the 
flag "IsFinal" is set to "false". This results in an 
infinite loop of "getLine" and "XML_Parse".

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 17:18

Message:
Logged In: YES 
user_id=3066

Either I can't reproduce this, or I don't understand the report.
I've added a regression test for this in tests/runtests.c 1.24.

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

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


From noreply@sourceforge.net  Tue Jul  9 22:48:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul  9 21:48:02 2002
Subject: [ expat-Bugs-579144 ] DLLs are not drop-in compatible
Message-ID: <E17S9Nz-0005c6-00@usw-sf-web1.sourceforge.net>

Bugs item #579144, was opened at 2002-07-09 11:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=579144&group_id=10127

Category: Build control
Group: Feature Request
Status: Open
Resolution: None
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: DLLs are not drop-in compatible

Initial Comment:
For Windows DLLs, Expat should be using a .DEF file
instead of __declspec(dllexport) to control the export
of symbols.  Using a .DEF file allows symbols to have
the same ordinal position in the export table of the
DLL regardless of accidents of the compiler's
organization of the table, allowing newer DLLs to
replace older DLLs by simply dropping them in place.

More information on DLL exports:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_core_determine_which_exporting_method_to_use.asp

This feature request is based on an email conversation
with Nick Lehman, following up from:
http://sourceforge.net/mailarchive/message.php?msg_id=1783043


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 00:47

Message:
Logged In: YES 
user_id=3066

It looks like the .DEF file should be easy enough to create,
and a nuissance to maintain.  I'm going to plan on getting
this done in the 1.95.5 release, since we're too close to
the 1.95.4 release to make a mess of things now.

The big question that comes up is this:  should the symbols
defined in lib/xmltok.h be exported, or only the symbols
from expat.h?  Originally, these were exported from two
separate DLLs, but it's not clear the API defined in
xmltok.h is really intended to be public.

If you have a reasoned opinion, or use the xmltok.h API,
please follow up to this feature request.

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

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


From noreply@sourceforge.net  Wed Jul 10 01:10:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed Jul 10 00:10:05 2002
Subject: [ expat-Bugs-579491 ] expat*.lib missing for Win32 linking
Message-ID: <E17SBbr-00081u-00@usw-sf-web1.sourceforge.net>

Bugs item #579491, was opened at 2002-07-10 10:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=579491&group_id=10127

Category: None
Group: Platform Specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Moshe Rubin (mrubin)
Assigned to: Nobody/Anonymous (nobody)
Summary: expat*.lib missing for Win32 linking

Initial Comment:
I downloaded expat_win32bin_1_95_1.zip.  Unzipping I 
found, among other files, expat_1_95_1.dll and expat.h.  
However, there was no expat_1_95_1.lib file to enable 
static linkage to expat_1_95_1.dll.

In the end, I created a expat_1_95_1.def file by 
extracting dependency information, and ran LIB to 
create the .lib file.  Not rocket science, but took 30 
minutes till I figured it out.

I'd like to contribute the .def and .lib file to the project.  
How can I do so?

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

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


From noreply@sourceforge.net  Wed Jul 10 07:25:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed Jul 10 06:25:08 2002
Subject: [ expat-Bugs-579144 ] DLLs are not drop-in compatible
Message-ID: <E17SHST-0005vh-00@usw-sf-web5.sourceforge.net>

Bugs item #579144, was opened at 2002-07-09 11:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=579144&group_id=10127

Category: Build control
Group: Feature Request
Status: Open
Resolution: None
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: DLLs are not drop-in compatible

Initial Comment:
For Windows DLLs, Expat should be using a .DEF file
instead of __declspec(dllexport) to control the export
of symbols.  Using a .DEF file allows symbols to have
the same ordinal position in the export table of the
DLL regardless of accidents of the compiler's
organization of the table, allowing newer DLLs to
replace older DLLs by simply dropping them in place.

More information on DLL exports:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_core_determine_which_exporting_method_to_use.asp

This feature request is based on an email conversation
with Nick Lehman, following up from:
http://sourceforge.net/mailarchive/message.php?msg_id=1783043


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-10 09:24

Message:
Logged In: YES 
user_id=290026

Fred,

are you sure a lot of people are reading this?

Karl

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 00:47

Message:
Logged In: YES 
user_id=3066

It looks like the .DEF file should be easy enough to create,
and a nuissance to maintain.  I'm going to plan on getting
this done in the 1.95.5 release, since we're too close to
the 1.95.4 release to make a mess of things now.

The big question that comes up is this:  should the symbols
defined in lib/xmltok.h be exported, or only the symbols
from expat.h?  Originally, these were exported from two
separate DLLs, but it's not clear the API defined in
xmltok.h is really intended to be public.

If you have a reasoned opinion, or use the xmltok.h API,
please follow up to this feature request.

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

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


From noreply@sourceforge.net  Wed Jul 10 09:39:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed Jul 10 08:39:03 2002
Subject: [ expat-Bugs-579491 ] expat*.lib missing for Win32 linking
Message-ID: <E17SJXm-0000nC-00@usw-sf-web2.sourceforge.net>

Bugs item #579491, was opened at 2002-07-10 03:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=579491&group_id=10127

>Category: Build control
Group: Platform Specific
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Moshe Rubin (mrubin)
Assigned to: Nobody/Anonymous (nobody)
Summary: expat*.lib missing for Win32 linking

Initial Comment:
I downloaded expat_win32bin_1_95_1.zip.  Unzipping I 
found, among other files, expat_1_95_1.dll and expat.h.  
However, there was no expat_1_95_1.lib file to enable 
static linkage to expat_1_95_1.dll.

In the end, I created a expat_1_95_1.def file by 
extracting dependency information, and ran LIB to 
create the .lib file.  Not rocket science, but took 30 
minutes till I figured it out.

I'd like to contribute the .def and .lib file to the project.  
How can I do so?

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 11:38

Message:
Logged In: YES 
user_id=3066

I'd like to see the .DEF file, actually, as we plan to move
away from __declspec(dllexport) to a .DEF file for exports.

The lack of the .LIB file has been addressed in Expat 1.95.2
and 1.95.3 (so I'm closing this bug report).  I'd recommend
using 1.95.2 instead of 1.95.1, at least until 1.95.4 is
out, hopefully later this week.

If you can send the .DEF file to me by email, I'd appreciate
it.  You can send it to fdrake at acm.org.

Thanks!

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

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


From noreply@sourceforge.net  Wed Jul 10 12:00:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed Jul 10 11:00:07 2002
Subject: [ expat-Bugs-491986 ] Charset decoding error (64-bit systems)
Message-ID: <E17SLkh-0005WD-00@usw-sf-web4.sourceforge.net>

Bugs item #491986, was opened at 2001-12-12 07:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=491986&group_id=10127

Category: None
>Group: Platform Specific
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: Bent Jensen (bentjensen)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Charset decoding error (64-bit systems)

Initial Comment:

When parsing xml with Danish letters (æøåÆØÅ) with 
eight bit set and declaring the encoding as <?xml 
version="1.0" encoding="iso-8859-1"?> (where the 
danish letters is placed as eight bit chars - the 
parser goes wrong.  If the input is:

  <person id="five.worker">
    <name><family>Worker</family> 
<given>Five</given></name>
    <email>J&oslash;rgen five@foo.com</email>
    <email>Jørgen five@foo.com</email>
    <link manager="Big.Boss"/>
  </person>


(Remark the danish letters in two forms)

The output is:

    START: email
CD: (null) - 'J' - 1
CD: (null) - 'rgen five@foo.com' - 17
END: email
CD: (null) - '
' - 1
CD: (null) - '    ' - 4
    START: email
CD: (null) - 'JÃ&#1567;rgen five@foo.com' - 20
END: email
CD: (null) - '
' - 1
CD: (null) - '    ' - 4

What am i doing wrong ?

If I embedd the string 'æøåÆØÅ' in the xml file - it 
goes all rigth ?!?!

I have modifyed the 'outline' example program for the 
above test.

Sincerly
Bent Jensen, Senior consultant.
bent@kiya.dk




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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 13:59

Message:
Logged In: YES 
user_id=3066

I just tried this on the Alpha system on the SourceForge
compile farm and the CVS version of Expat, and the
regression test I added doesn't trigger.  Can you still
reproduce this with the CVS version of Expat?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-19 15:45

Message:
Logged In: YES 
user_id=3066

Good point.  I've re-opened the report and noted the 64-bit
dependency in the summary.

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

Comment By: Bent Jensen (bentjensen)
Date: 2002-04-19 15:14

Message:
Logged In: YES 
user_id=392963

Hi again

I have tried all combinations of telleing the parset that i 
want to use iso-8859-1 encoding - also to the 
XML_ParserCreate function. 

But you have to remark that i am running on a 64 bit 
machine and in the routine where you are reading the input 
chars you are doing bit shifts 'en masse' - and here 
everything can goes wrong - bitshifts are not portable !

Sincerly 
Bent Jensen, Senior consultant. 
bent@kiya.dk 



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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-19 14:46

Message:
Logged In: YES 
user_id=3066

I cannot reproduce this using CVS Expat.  I've added a
regression test for this to be sure it doesn't crop up
(tests/runtests.c revision 1.7).

Make sure that you're passing either NULL or "iso-8859-1" to
the XML_ParserCreate*() function as the encoding name.

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

Comment By: Bent Jensen (bentjensen)
Date: 2001-12-12 07:56

Message:
Logged In: YES 
user_id=392963

Info: The expat package (version 1.95.2) was build on 
alpha/axp OSF1 4.0D with gcc version 2.95.3. The test was 
run on the same machine.

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

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


From noreply@sourceforge.net  Wed Jul 10 17:01:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed Jul 10 16:01:04 2002
Subject: [ expat-Patches-538032 ] Borland Win32 project & makefiles
Message-ID: <E17SQRw-00019e-00@usw-sf-web1.sourceforge.net>

Patches item #538032, was opened at 2002-04-01 16:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=538032&group_id=10127

Category: Build Control
Group: Feature Request
Status: Closed
Resolution: Out of Date
Priority: 5
Submitted By: Patrick McConnell (pmcconnell)
Assigned to: Nobody/Anonymous (nobody)
Summary: Borland Win32 project & makefiles

Initial Comment:
Borland C++ Builder project file and make file for the 
command line compiler to build expat.dll

Unzip the patch from the directory above expat, then 
read the README.borland file for instructions.

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

>Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-10 19:00

Message:
Logged In: YES 
user_id=415653

Ahh, I didnt clue in that you wanted me to do something 
previously. I have been keeping my proj and makefiles up 
to date and have attached the latest. They should go into 
expat/proj/win32/BCB5 (I did this instead of spreading 
them around the directory tree to reduce clutter).

You can test it with the free Borland command line 
compiler, the make files work with that. 
http://www.borland.com/products/downloads/download_cb
uilder.html

If you are getting close to a release and want to include this 
I'll check it out on a daily basis. Im using the cvs files.

Patrick

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 16:31

Message:
Logged In: YES 
user_id=3066

Closing due to non-responsiveness of the reporter and
generally not being able to bring this up to date.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 18:39

Message:
Logged In: YES 
user_id=3066

Well, I won't be able to install the C++ Builder demo on my Win2K 
system since I don't have enough space on my system disk.  ;-(

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 00:04

Message:
Logged In: YES 
user_id=3066

Does this need to be updated to reflect the header name change from 
"config.h" to "expat_config.h"?

I don't think I'll have time to look at 
this before 1.95.3; is this just a few additional files or do other files need 
changing?  I'll try to install the recent C++ Builder demo to try this out.

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

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


From noreply@sourceforge.net  Wed Jul 10 19:30:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed Jul 10 18:30:04 2002
Subject: [ expat-Patches-538032 ] Borland Win32 project & makefiles
Message-ID: <E17SSmL-00061p-00@usw-sf-web4.sourceforge.net>

Patches item #538032, was opened at 2002-04-01 16:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=538032&group_id=10127

Category: Build Control
Group: Feature Request
>Status: Open
Resolution: Out of Date
Priority: 5
Submitted By: Patrick McConnell (pmcconnell)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Borland Win32 project & makefiles

Initial Comment:
Borland C++ Builder project file and make file for the 
command line compiler to build expat.dll

Unzip the patch from the directory above expat, then 
read the README.borland file for instructions.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 21:29

Message:
Logged In: YES 
user_id=3066

Re-opened and assigned to myself.

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

Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-10 19:00

Message:
Logged In: YES 
user_id=415653

Ahh, I didnt clue in that you wanted me to do something 
previously. I have been keeping my proj and makefiles up 
to date and have attached the latest. They should go into 
expat/proj/win32/BCB5 (I did this instead of spreading 
them around the directory tree to reduce clutter).

You can test it with the free Borland command line 
compiler, the make files work with that. 
http://www.borland.com/products/downloads/download_cb
uilder.html

If you are getting close to a release and want to include this 
I'll check it out on a daily basis. Im using the cvs files.

Patrick

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 16:31

Message:
Logged In: YES 
user_id=3066

Closing due to non-responsiveness of the reporter and
generally not being able to bring this up to date.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 18:39

Message:
Logged In: YES 
user_id=3066

Well, I won't be able to install the C++ Builder demo on my Win2K 
system since I don't have enough space on my system disk.  ;-(

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 00:04

Message:
Logged In: YES 
user_id=3066

Does this need to be updated to reflect the header name change from 
"config.h" to "expat_config.h"?

I don't think I'll have time to look at 
this before 1.95.3; is this just a few additional files or do other files need 
changing?  I'll try to install the recent C++ Builder demo to try this out.

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

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


From noreply@sourceforge.net  Wed Jul 10 21:03:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed Jul 10 20:03:01 2002
Subject: [ expat-Patches-538032 ] Borland Win32 project & makefiles
Message-ID: <E17SUDm-0003UX-00@usw-sf-web2.sourceforge.net>

Patches item #538032, was opened at 2002-04-01 16:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=538032&group_id=10127

Category: Build Control
Group: Feature Request
>Status: Pending
Resolution: Out of Date
Priority: 5
Submitted By: Patrick McConnell (pmcconnell)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Borland Win32 project & makefiles

Initial Comment:
Borland C++ Builder project file and make file for the 
command line compiler to build expat.dll

Unzip the patch from the directory above expat, then 
read the README.borland file for instructions.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 23:02

Message:
Logged In: YES 
user_id=3066

After a quick review:

I'd like to rename the "cleanall" target to simply "clean",
as this is a more common name for this function.

There appear to be many intermediate directories between the
top of the tree and the BCB5 directory; can this be reduced?
 I'm also not sure if the expected structure is that
resulting from the installed version of the sources or just
the CVS checkout; it's largely the same, but slightly
different at the top (probably not in any relevant way).  It
appears slightly tedious to make this work easily in both
tree structures, since the win32/ directory is not part of
the Source/ directory of the installed Expat package.

I still haven't had time to re-install my Windows
environment, so I can't yet install Borland's free
command-line compiler, so I'll need your guidance.  ;-(

We are getting ready to release Expat 1.95.4 this coming Friday.

Marking this report "pending", awaiting your response.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 21:29

Message:
Logged In: YES 
user_id=3066

Re-opened and assigned to myself.

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

Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-10 19:00

Message:
Logged In: YES 
user_id=415653

Ahh, I didnt clue in that you wanted me to do something 
previously. I have been keeping my proj and makefiles up 
to date and have attached the latest. They should go into 
expat/proj/win32/BCB5 (I did this instead of spreading 
them around the directory tree to reduce clutter).

You can test it with the free Borland command line 
compiler, the make files work with that. 
http://www.borland.com/products/downloads/download_cb
uilder.html

If you are getting close to a release and want to include this 
I'll check it out on a daily basis. Im using the cvs files.

Patrick

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 16:31

Message:
Logged In: YES 
user_id=3066

Closing due to non-responsiveness of the reporter and
generally not being able to bring this up to date.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 18:39

Message:
Logged In: YES 
user_id=3066

Well, I won't be able to install the C++ Builder demo on my Win2K 
system since I don't have enough space on my system disk.  ;-(

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 00:04

Message:
Logged In: YES 
user_id=3066

Does this need to be updated to reflect the header name change from 
"config.h" to "expat_config.h"?

I don't think I'll have time to look at 
this before 1.95.3; is this just a few additional files or do other files need 
changing?  I'll try to install the recent C++ Builder demo to try this out.

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

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


From noreply@sourceforge.net  Thu Jul 11 03:47:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu Jul 11 02:47:03 2002
Subject: [ expat-Bugs-579491 ] expat*.lib missing for Win32 linking
Message-ID: <E17SaWw-0000vz-00@usw-sf-web3.sourceforge.net>

Bugs item #579491, was opened at 2002-07-10 10:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=579491&group_id=10127

Category: Build control
Group: Platform Specific
Status: Closed
Resolution: Out of Date
Priority: 5
Submitted By: Moshe Rubin (mrubin)
Assigned to: Nobody/Anonymous (nobody)
Summary: expat*.lib missing for Win32 linking

Initial Comment:
I downloaded expat_win32bin_1_95_1.zip.  Unzipping I 
found, among other files, expat_1_95_1.dll and expat.h.  
However, there was no expat_1_95_1.lib file to enable 
static linkage to expat_1_95_1.dll.

In the end, I created a expat_1_95_1.def file by 
extracting dependency information, and ran LIB to 
create the .lib file.  Not rocket science, but took 30 
minutes till I figured it out.

I'd like to contribute the .def and .lib file to the project.  
How can I do so?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 18:38

Message:
Logged In: YES 
user_id=3066

I'd like to see the .DEF file, actually, as we plan to move
away from __declspec(dllexport) to a .DEF file for exports.

The lack of the .LIB file has been addressed in Expat 1.95.2
and 1.95.3 (so I'm closing this bug report).  I'd recommend
using 1.95.2 instead of 1.95.1, at least until 1.95.4 is
out, hopefully later this week.

If you can send the .DEF file to me by email, I'd appreciate
it.  You can send it to fdrake at acm.org.

Thanks!

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

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


From noreply@sourceforge.net  Thu Jul 11 10:32:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu Jul 11 09:32:05 2002
Subject: [ expat-Patches-538032 ] Borland Win32 project & makefiles
Message-ID: <E17SgqS-00053h-00@usw-sf-web5.sourceforge.net>

Patches item #538032, was opened at 2002-04-01 16:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=538032&group_id=10127

Category: Build Control
Group: Feature Request
>Status: Open
Resolution: Out of Date
Priority: 5
Submitted By: Patrick McConnell (pmcconnell)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Borland Win32 project & makefiles

Initial Comment:
Borland C++ Builder project file and make file for the 
command line compiler to build expat.dll

Unzip the patch from the directory above expat, then 
read the README.borland file for instructions.

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

>Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-11 12:31

Message:
Logged In: YES 
user_id=415653

Fred,

The directory structure I used for the project files is copied 
from easysoap and xerces-c. It is more than expat needs 
at this point but if you start getting more and more ports to 
other OS's and build tools it becomes necessary. For 
example, your VC files could go into expat/proj/win32/VC6. 
However, if you like, I can put everything into a directory 
called BCB5 right under the expat root.

cleanall removes the executables, obj files and the build 
directories. Instead of renaming it, I'll just create another 
target called clean that only removes the obj files. I think 
this is more standard. OK?

About the directory structure: I was assuming the cvs is 
the same as the release structure. My build files are now 
set up to put the binaries in "release" directories under the 
various source directories (lib, examples, xmlwf and 
gennmtab). Are you saying the installed directory structure 
has all the source directories under src (or Source)? Also, 
for the release, should all the binaries go into expat/win32? 
I can do this no problem, just let me know.

I got the setup Im using now by translating the VC project 
files into BCB format, so I figured it would be right, but I 
never thought the installed structure would be different 
from the cvs.

Patrick

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 23:02

Message:
Logged In: YES 
user_id=3066

After a quick review:

I'd like to rename the "cleanall" target to simply "clean",
as this is a more common name for this function.

There appear to be many intermediate directories between the
top of the tree and the BCB5 directory; can this be reduced?
 I'm also not sure if the expected structure is that
resulting from the installed version of the sources or just
the CVS checkout; it's largely the same, but slightly
different at the top (probably not in any relevant way).  It
appears slightly tedious to make this work easily in both
tree structures, since the win32/ directory is not part of
the Source/ directory of the installed Expat package.

I still haven't had time to re-install my Windows
environment, so I can't yet install Borland's free
command-line compiler, so I'll need your guidance.  ;-(

We are getting ready to release Expat 1.95.4 this coming Friday.

Marking this report "pending", awaiting your response.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 21:29

Message:
Logged In: YES 
user_id=3066

Re-opened and assigned to myself.

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

Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-10 19:00

Message:
Logged In: YES 
user_id=415653

Ahh, I didnt clue in that you wanted me to do something 
previously. I have been keeping my proj and makefiles up 
to date and have attached the latest. They should go into 
expat/proj/win32/BCB5 (I did this instead of spreading 
them around the directory tree to reduce clutter).

You can test it with the free Borland command line 
compiler, the make files work with that. 
http://www.borland.com/products/downloads/download_cb
uilder.html

If you are getting close to a release and want to include this 
I'll check it out on a daily basis. Im using the cvs files.

Patrick

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 16:31

Message:
Logged In: YES 
user_id=3066

Closing due to non-responsiveness of the reporter and
generally not being able to bring this up to date.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 18:39

Message:
Logged In: YES 
user_id=3066

Well, I won't be able to install the C++ Builder demo on my Win2K 
system since I don't have enough space on my system disk.  ;-(

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 00:04

Message:
Logged In: YES 
user_id=3066

Does this need to be updated to reflect the header name change from 
"config.h" to "expat_config.h"?

I don't think I'll have time to look at 
this before 1.95.3; is this just a few additional files or do other files need 
changing?  I'll try to install the recent C++ Builder demo to try this out.

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

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


From noreply@sourceforge.net  Thu Jul 11 11:02:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu Jul 11 10:02:03 2002
Subject: [ expat-Patches-538032 ] Borland Win32 project & makefiles
Message-ID: <E17ShJe-0006Pe-00@usw-sf-web4.sourceforge.net>

Patches item #538032, was opened at 2002-04-01 16:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=538032&group_id=10127

Category: Build Control
Group: Feature Request
Status: Open
Resolution: Out of Date
Priority: 5
Submitted By: Patrick McConnell (pmcconnell)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Borland Win32 project & makefiles

Initial Comment:
Borland C++ Builder project file and make file for the 
command line compiler to build expat.dll

Unzip the patch from the directory above expat, then 
read the README.borland file for instructions.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 13:01

Message:
Logged In: YES 
user_id=3066

Regarding the clean and cleanall targets:  You're right, the
new version of clean you describe would be better, and
"cleanall" should probably be named "distclean", and should
remove everything created in the process of running the
makefile (including DLLs, .LIB files, etc.).

The MSVC project works because the directories it needs are
all arranged the same way for both CVS checkouts and the
"installed" sources.  You might want to look at
win32/MANIFEST.txt; it describes the layout of the installed
package on Windows.  There is no equivalent of the win32
directory in the result; I'd imagined putting the BCB5
directory inside that.  I think I could copy the directory
to Sources\BCB5 using the installer, but that makes it one
level closer to the top of the source tree in the installed
version than in CVS, which breaks the use of ..\.. references.

I like the idea of keeping the project files away from the
actual sources though.  Perhaps I can change the MSVC
projects to work in a similar way, but I'm hesitant to make
so many changes to the structure just before tomorrow's release.

(Karl, any thoughts on moving the .DSP and .DSW files to
win32\msvc6 ?)

Would it be reasonable to adjust the files to work from
win32\bcb5, and only worry about them from CVS for now,
leaving them out of the installer in 1.95.4.  Re-working the
project file layout can be done for 1.95.5, so it can be
given more thought.

Thanks!

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

Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-11 12:31

Message:
Logged In: YES 
user_id=415653

Fred,

The directory structure I used for the project files is copied 
from easysoap and xerces-c. It is more than expat needs 
at this point but if you start getting more and more ports to 
other OS's and build tools it becomes necessary. For 
example, your VC files could go into expat/proj/win32/VC6. 
However, if you like, I can put everything into a directory 
called BCB5 right under the expat root.

cleanall removes the executables, obj files and the build 
directories. Instead of renaming it, I'll just create another 
target called clean that only removes the obj files. I think 
this is more standard. OK?

About the directory structure: I was assuming the cvs is 
the same as the release structure. My build files are now 
set up to put the binaries in "release" directories under the 
various source directories (lib, examples, xmlwf and 
gennmtab). Are you saying the installed directory structure 
has all the source directories under src (or Source)? Also, 
for the release, should all the binaries go into expat/win32? 
I can do this no problem, just let me know.

I got the setup Im using now by translating the VC project 
files into BCB format, so I figured it would be right, but I 
never thought the installed structure would be different 
from the cvs.

Patrick

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 23:02

Message:
Logged In: YES 
user_id=3066

After a quick review:

I'd like to rename the "cleanall" target to simply "clean",
as this is a more common name for this function.

There appear to be many intermediate directories between the
top of the tree and the BCB5 directory; can this be reduced?
 I'm also not sure if the expected structure is that
resulting from the installed version of the sources or just
the CVS checkout; it's largely the same, but slightly
different at the top (probably not in any relevant way).  It
appears slightly tedious to make this work easily in both
tree structures, since the win32/ directory is not part of
the Source/ directory of the installed Expat package.

I still haven't had time to re-install my Windows
environment, so I can't yet install Borland's free
command-line compiler, so I'll need your guidance.  ;-(

We are getting ready to release Expat 1.95.4 this coming Friday.

Marking this report "pending", awaiting your response.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 21:29

Message:
Logged In: YES 
user_id=3066

Re-opened and assigned to myself.

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

Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-10 19:00

Message:
Logged In: YES 
user_id=415653

Ahh, I didnt clue in that you wanted me to do something 
previously. I have been keeping my proj and makefiles up 
to date and have attached the latest. They should go into 
expat/proj/win32/BCB5 (I did this instead of spreading 
them around the directory tree to reduce clutter).

You can test it with the free Borland command line 
compiler, the make files work with that. 
http://www.borland.com/products/downloads/download_cb
uilder.html

If you are getting close to a release and want to include this 
I'll check it out on a daily basis. Im using the cvs files.

Patrick

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 16:31

Message:
Logged In: YES 
user_id=3066

Closing due to non-responsiveness of the reporter and
generally not being able to bring this up to date.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 18:39

Message:
Logged In: YES 
user_id=3066

Well, I won't be able to install the C++ Builder demo on my Win2K 
system since I don't have enough space on my system disk.  ;-(

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 00:04

Message:
Logged In: YES 
user_id=3066

Does this need to be updated to reflect the header name change from 
"config.h" to "expat_config.h"?

I don't think I'll have time to look at 
this before 1.95.3; is this just a few additional files or do other files need 
changing?  I'll try to install the recent C++ Builder demo to try this out.

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

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


From noreply@sourceforge.net  Thu Jul 11 11:11:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu Jul 11 10:11:06 2002
Subject: [ expat-Bugs-566238 ] 1.95.3: xmlwf startup time much longer
Message-ID: <E17ShSY-0006bC-00@usw-sf-web4.sourceforge.net>

Bugs item #566238, was opened at 2002-06-08 10:29
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=566238&group_id=10127

Category: Build control
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Rolf Ade (pointsman)
Assigned to: Greg Stein (gstein)
Summary: 1.95.3: xmlwf startup time much longer

Initial Comment:

At least at my linux box, I seems that the new way of
starting xmlwf - with a shell wrapper - heavily
increases the startup time of xmlwf.

For most people, this may be a really minor problem (it
isn't even a big one for me, though). But if you check
a lot of really small xml files with xmlwf in  one
commandline or a shell script, this is very notable. 

I've noticed it, while checking the (very small) test
files of the OASIS test suite. My shell scripts, that
does this, needed up to 10 times (!) longer, to finished.

To be sure, it's really the startup time, I checked
xmlwf against some bigger XML files (around 30 Mbyte)
and found only minor speed differences between 1.95.2
and 1.95.3. It seems, 1.95.3 is around 6 or 7 percent
slower than 1.95.2 (I've substracted the mesured longer
startup time of the 1.95.3 xmlwf from the running time,
befor calculation.)

rolf


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

>Comment By: Greg Stein (gstein)
Date: 2002-07-11 10:10

Message:
Logged In: YES 
user_id=6501

Rolf,

Was your slower time measured against xmlwf out of the build
tree, or an installed copy? As far as I can tell, we never
install the shell script wrapper. Within the build tree, it
will always be present (the first run will be slow while it
links, then it should be faster (but not as fast as without
the shell script, of course))

Anyways... we need to find out if your observation was for
the build or installed copy of xmlwf.

thx.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-29 08:28

Message:
Logged In: YES 
user_id=3066

This is painful, but not enough to hold up a bugfix release.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-25 21:58

Message:
Logged In: YES 
user_id=3066

Ugh!  This is heinous!  The crufty libtool wrapper should
never be installed, and even says so itself.

Greg, can you fix this soon?

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

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


From noreply@sourceforge.net  Thu Jul 11 11:16:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu Jul 11 10:16:02 2002
Subject: [ expat-Patches-538032 ] Borland Win32 project & makefiles
Message-ID: <E17ShX2-0005wC-00@usw-sf-web5.sourceforge.net>

Patches item #538032, was opened at 2002-04-01 16:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=538032&group_id=10127

Category: Build Control
Group: Feature Request
Status: Open
Resolution: Out of Date
Priority: 5
Submitted By: Patrick McConnell (pmcconnell)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Borland Win32 project & makefiles

Initial Comment:
Borland C++ Builder project file and make file for the 
command line compiler to build expat.dll

Unzip the patch from the directory above expat, then 
read the README.borland file for instructions.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 13:15

Message:
Logged In: YES 
user_id=290026

>  (Karl, any thoughts on moving the .DSP and .DSW
>  files to win32\msvc6 ?)

Well, ideally I would like it symmetrical, i.e. all
the build files for the various targets should be
in separate directories on the same level.

It seems it is not that clear that we should have an extra
level for the OS, since Windows Dlls can be built on 
VC6, BCB5 and Cygwin.

Also, the Make stuff may apply to various OSes 
simultaneously. So, maybe we could have the Make stuff
at the top level, as we already have, and create one
child directory for each build target that needs special
treatment beyond Make. In other words, I am
thinking off a VC6 directory and a BCB5 directory directly
under the top level (I believe you already have a vms 
directory like that).

Karl



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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 13:01

Message:
Logged In: YES 
user_id=3066

Regarding the clean and cleanall targets:  You're right, the
new version of clean you describe would be better, and
"cleanall" should probably be named "distclean", and should
remove everything created in the process of running the
makefile (including DLLs, .LIB files, etc.).

The MSVC project works because the directories it needs are
all arranged the same way for both CVS checkouts and the
"installed" sources.  You might want to look at
win32/MANIFEST.txt; it describes the layout of the installed
package on Windows.  There is no equivalent of the win32
directory in the result; I'd imagined putting the BCB5
directory inside that.  I think I could copy the directory
to Sources\BCB5 using the installer, but that makes it one
level closer to the top of the source tree in the installed
version than in CVS, which breaks the use of ..\.. references.

I like the idea of keeping the project files away from the
actual sources though.  Perhaps I can change the MSVC
projects to work in a similar way, but I'm hesitant to make
so many changes to the structure just before tomorrow's release.

(Karl, any thoughts on moving the .DSP and .DSW files to
win32\msvc6 ?)

Would it be reasonable to adjust the files to work from
win32\bcb5, and only worry about them from CVS for now,
leaving them out of the installer in 1.95.4.  Re-working the
project file layout can be done for 1.95.5, so it can be
given more thought.

Thanks!

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

Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-11 12:31

Message:
Logged In: YES 
user_id=415653

Fred,

The directory structure I used for the project files is copied 
from easysoap and xerces-c. It is more than expat needs 
at this point but if you start getting more and more ports to 
other OS's and build tools it becomes necessary. For 
example, your VC files could go into expat/proj/win32/VC6. 
However, if you like, I can put everything into a directory 
called BCB5 right under the expat root.

cleanall removes the executables, obj files and the build 
directories. Instead of renaming it, I'll just create another 
target called clean that only removes the obj files. I think 
this is more standard. OK?

About the directory structure: I was assuming the cvs is 
the same as the release structure. My build files are now 
set up to put the binaries in "release" directories under the 
various source directories (lib, examples, xmlwf and 
gennmtab). Are you saying the installed directory structure 
has all the source directories under src (or Source)? Also, 
for the release, should all the binaries go into expat/win32? 
I can do this no problem, just let me know.

I got the setup Im using now by translating the VC project 
files into BCB format, so I figured it would be right, but I 
never thought the installed structure would be different 
from the cvs.

Patrick

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 23:02

Message:
Logged In: YES 
user_id=3066

After a quick review:

I'd like to rename the "cleanall" target to simply "clean",
as this is a more common name for this function.

There appear to be many intermediate directories between the
top of the tree and the BCB5 directory; can this be reduced?
 I'm also not sure if the expected structure is that
resulting from the installed version of the sources or just
the CVS checkout; it's largely the same, but slightly
different at the top (probably not in any relevant way).  It
appears slightly tedious to make this work easily in both
tree structures, since the win32/ directory is not part of
the Source/ directory of the installed Expat package.

I still haven't had time to re-install my Windows
environment, so I can't yet install Borland's free
command-line compiler, so I'll need your guidance.  ;-(

We are getting ready to release Expat 1.95.4 this coming Friday.

Marking this report "pending", awaiting your response.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 21:29

Message:
Logged In: YES 
user_id=3066

Re-opened and assigned to myself.

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

Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-10 19:00

Message:
Logged In: YES 
user_id=415653

Ahh, I didnt clue in that you wanted me to do something 
previously. I have been keeping my proj and makefiles up 
to date and have attached the latest. They should go into 
expat/proj/win32/BCB5 (I did this instead of spreading 
them around the directory tree to reduce clutter).

You can test it with the free Borland command line 
compiler, the make files work with that. 
http://www.borland.com/products/downloads/download_cb
uilder.html

If you are getting close to a release and want to include this 
I'll check it out on a daily basis. Im using the cvs files.

Patrick

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 16:31

Message:
Logged In: YES 
user_id=3066

Closing due to non-responsiveness of the reporter and
generally not being able to bring this up to date.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 18:39

Message:
Logged In: YES 
user_id=3066

Well, I won't be able to install the C++ Builder demo on my Win2K 
system since I don't have enough space on my system disk.  ;-(

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 00:04

Message:
Logged In: YES 
user_id=3066

Does this need to be updated to reflect the header name change from 
"config.h" to "expat_config.h"?

I don't think I'll have time to look at 
this before 1.95.3; is this just a few additional files or do other files need 
changing?  I'll try to install the recent C++ Builder demo to try this out.

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

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


From noreply@sourceforge.net  Thu Jul 11 11:55:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu Jul 11 10:55:07 2002
Subject: [ expat-Patches-538032 ] Borland Win32 project & makefiles
Message-ID: <E17Si9U-0005DK-00@usw-sf-web1.sourceforge.net>

Patches item #538032, was opened at 2002-04-01 16:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=538032&group_id=10127

Category: Build Control
Group: Feature Request
Status: Open
Resolution: Out of Date
Priority: 5
Submitted By: Patrick McConnell (pmcconnell)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Borland Win32 project & makefiles

Initial Comment:
Borland C++ Builder project file and make file for the 
command line compiler to build expat.dll

Unzip the patch from the directory above expat, then 
read the README.borland file for instructions.

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

>Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-11 13:54

Message:
Logged In: YES 
user_id=415653

Why dont I put the BCB files in expat/BCB5. Then the 
make files will be there ready to by integrated into the top 
level make files at a later date. Also, the VC proj's put the 
binaries in various "release" directories but since the BCB 
files are all in one place why dont I just put the binaries in 
expat/win32/release. Finally, should I copy the libs to 
expat/Lib? I can do all this today if you want to include it in 
tomorrows release.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 13:15

Message:
Logged In: YES 
user_id=290026

>  (Karl, any thoughts on moving the .DSP and .DSW
>  files to win32\msvc6 ?)

Well, ideally I would like it symmetrical, i.e. all
the build files for the various targets should be
in separate directories on the same level.

It seems it is not that clear that we should have an extra
level for the OS, since Windows Dlls can be built on 
VC6, BCB5 and Cygwin.

Also, the Make stuff may apply to various OSes 
simultaneously. So, maybe we could have the Make stuff
at the top level, as we already have, and create one
child directory for each build target that needs special
treatment beyond Make. In other words, I am
thinking off a VC6 directory and a BCB5 directory directly
under the top level (I believe you already have a vms 
directory like that).

Karl



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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 13:01

Message:
Logged In: YES 
user_id=3066

Regarding the clean and cleanall targets:  You're right, the
new version of clean you describe would be better, and
"cleanall" should probably be named "distclean", and should
remove everything created in the process of running the
makefile (including DLLs, .LIB files, etc.).

The MSVC project works because the directories it needs are
all arranged the same way for both CVS checkouts and the
"installed" sources.  You might want to look at
win32/MANIFEST.txt; it describes the layout of the installed
package on Windows.  There is no equivalent of the win32
directory in the result; I'd imagined putting the BCB5
directory inside that.  I think I could copy the directory
to Sources\BCB5 using the installer, but that makes it one
level closer to the top of the source tree in the installed
version than in CVS, which breaks the use of ..\.. references.

I like the idea of keeping the project files away from the
actual sources though.  Perhaps I can change the MSVC
projects to work in a similar way, but I'm hesitant to make
so many changes to the structure just before tomorrow's release.

(Karl, any thoughts on moving the .DSP and .DSW files to
win32\msvc6 ?)

Would it be reasonable to adjust the files to work from
win32\bcb5, and only worry about them from CVS for now,
leaving them out of the installer in 1.95.4.  Re-working the
project file layout can be done for 1.95.5, so it can be
given more thought.

Thanks!

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

Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-11 12:31

Message:
Logged In: YES 
user_id=415653

Fred,

The directory structure I used for the project files is copied 
from easysoap and xerces-c. It is more than expat needs 
at this point but if you start getting more and more ports to 
other OS's and build tools it becomes necessary. For 
example, your VC files could go into expat/proj/win32/VC6. 
However, if you like, I can put everything into a directory 
called BCB5 right under the expat root.

cleanall removes the executables, obj files and the build 
directories. Instead of renaming it, I'll just create another 
target called clean that only removes the obj files. I think 
this is more standard. OK?

About the directory structure: I was assuming the cvs is 
the same as the release structure. My build files are now 
set up to put the binaries in "release" directories under the 
various source directories (lib, examples, xmlwf and 
gennmtab). Are you saying the installed directory structure 
has all the source directories under src (or Source)? Also, 
for the release, should all the binaries go into expat/win32? 
I can do this no problem, just let me know.

I got the setup Im using now by translating the VC project 
files into BCB format, so I figured it would be right, but I 
never thought the installed structure would be different 
from the cvs.

Patrick

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 23:02

Message:
Logged In: YES 
user_id=3066

After a quick review:

I'd like to rename the "cleanall" target to simply "clean",
as this is a more common name for this function.

There appear to be many intermediate directories between the
top of the tree and the BCB5 directory; can this be reduced?
 I'm also not sure if the expected structure is that
resulting from the installed version of the sources or just
the CVS checkout; it's largely the same, but slightly
different at the top (probably not in any relevant way).  It
appears slightly tedious to make this work easily in both
tree structures, since the win32/ directory is not part of
the Source/ directory of the installed Expat package.

I still haven't had time to re-install my Windows
environment, so I can't yet install Borland's free
command-line compiler, so I'll need your guidance.  ;-(

We are getting ready to release Expat 1.95.4 this coming Friday.

Marking this report "pending", awaiting your response.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 21:29

Message:
Logged In: YES 
user_id=3066

Re-opened and assigned to myself.

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

Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-10 19:00

Message:
Logged In: YES 
user_id=415653

Ahh, I didnt clue in that you wanted me to do something 
previously. I have been keeping my proj and makefiles up 
to date and have attached the latest. They should go into 
expat/proj/win32/BCB5 (I did this instead of spreading 
them around the directory tree to reduce clutter).

You can test it with the free Borland command line 
compiler, the make files work with that. 
http://www.borland.com/products/downloads/download_cb
uilder.html

If you are getting close to a release and want to include this 
I'll check it out on a daily basis. Im using the cvs files.

Patrick

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 16:31

Message:
Logged In: YES 
user_id=3066

Closing due to non-responsiveness of the reporter and
generally not being able to bring this up to date.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 18:39

Message:
Logged In: YES 
user_id=3066

Well, I won't be able to install the C++ Builder demo on my Win2K 
system since I don't have enough space on my system disk.  ;-(

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 00:04

Message:
Logged In: YES 
user_id=3066

Does this need to be updated to reflect the header name change from 
"config.h" to "expat_config.h"?

I don't think I'll have time to look at 
this before 1.95.3; is this just a few additional files or do other files need 
changing?  I'll try to install the recent C++ Builder demo to try this out.

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

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


From noreply@sourceforge.net  Thu Jul 11 12:02:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu Jul 11 11:02:10 2002
Subject: [ expat-Patches-538032 ] Borland Win32 project & makefiles
Message-ID: <E17SiGI-0000Rs-00@usw-sf-web3.sourceforge.net>

Patches item #538032, was opened at 2002-04-01 16:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=538032&group_id=10127

Category: Build Control
Group: Feature Request
Status: Open
Resolution: Out of Date
Priority: 5
Submitted By: Patrick McConnell (pmcconnell)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Borland Win32 project & makefiles

Initial Comment:
Borland C++ Builder project file and make file for the 
command line compiler to build expat.dll

Unzip the patch from the directory above expat, then 
read the README.borland file for instructions.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 14:01

Message:
Logged In: YES 
user_id=290026

I am wondering if each build target should not have its 
own "release" type directoy? Imagine you want to 
maintain separate builds of Expat under VC6 and BCB5.
In that case it would be nice if they would not overwrite 
each other. But maybe that is too fancy.

Karl

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

Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-11 13:54

Message:
Logged In: YES 
user_id=415653

Why dont I put the BCB files in expat/BCB5. Then the 
make files will be there ready to by integrated into the top 
level make files at a later date. Also, the VC proj's put the 
binaries in various "release" directories but since the BCB 
files are all in one place why dont I just put the binaries in 
expat/win32/release. Finally, should I copy the libs to 
expat/Lib? I can do all this today if you want to include it in 
tomorrows release.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 13:15

Message:
Logged In: YES 
user_id=290026

>  (Karl, any thoughts on moving the .DSP and .DSW
>  files to win32\msvc6 ?)

Well, ideally I would like it symmetrical, i.e. all
the build files for the various targets should be
in separate directories on the same level.

It seems it is not that clear that we should have an extra
level for the OS, since Windows Dlls can be built on 
VC6, BCB5 and Cygwin.

Also, the Make stuff may apply to various OSes 
simultaneously. So, maybe we could have the Make stuff
at the top level, as we already have, and create one
child directory for each build target that needs special
treatment beyond Make. In other words, I am
thinking off a VC6 directory and a BCB5 directory directly
under the top level (I believe you already have a vms 
directory like that).

Karl



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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 13:01

Message:
Logged In: YES 
user_id=3066

Regarding the clean and cleanall targets:  You're right, the
new version of clean you describe would be better, and
"cleanall" should probably be named "distclean", and should
remove everything created in the process of running the
makefile (including DLLs, .LIB files, etc.).

The MSVC project works because the directories it needs are
all arranged the same way for both CVS checkouts and the
"installed" sources.  You might want to look at
win32/MANIFEST.txt; it describes the layout of the installed
package on Windows.  There is no equivalent of the win32
directory in the result; I'd imagined putting the BCB5
directory inside that.  I think I could copy the directory
to Sources\BCB5 using the installer, but that makes it one
level closer to the top of the source tree in the installed
version than in CVS, which breaks the use of ..\.. references.

I like the idea of keeping the project files away from the
actual sources though.  Perhaps I can change the MSVC
projects to work in a similar way, but I'm hesitant to make
so many changes to the structure just before tomorrow's release.

(Karl, any thoughts on moving the .DSP and .DSW files to
win32\msvc6 ?)

Would it be reasonable to adjust the files to work from
win32\bcb5, and only worry about them from CVS for now,
leaving them out of the installer in 1.95.4.  Re-working the
project file layout can be done for 1.95.5, so it can be
given more thought.

Thanks!

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

Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-11 12:31

Message:
Logged In: YES 
user_id=415653

Fred,

The directory structure I used for the project files is copied 
from easysoap and xerces-c. It is more than expat needs 
at this point but if you start getting more and more ports to 
other OS's and build tools it becomes necessary. For 
example, your VC files could go into expat/proj/win32/VC6. 
However, if you like, I can put everything into a directory 
called BCB5 right under the expat root.

cleanall removes the executables, obj files and the build 
directories. Instead of renaming it, I'll just create another 
target called clean that only removes the obj files. I think 
this is more standard. OK?

About the directory structure: I was assuming the cvs is 
the same as the release structure. My build files are now 
set up to put the binaries in "release" directories under the 
various source directories (lib, examples, xmlwf and 
gennmtab). Are you saying the installed directory structure 
has all the source directories under src (or Source)? Also, 
for the release, should all the binaries go into expat/win32? 
I can do this no problem, just let me know.

I got the setup Im using now by translating the VC project 
files into BCB format, so I figured it would be right, but I 
never thought the installed structure would be different 
from the cvs.

Patrick

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 23:02

Message:
Logged In: YES 
user_id=3066

After a quick review:

I'd like to rename the "cleanall" target to simply "clean",
as this is a more common name for this function.

There appear to be many intermediate directories between the
top of the tree and the BCB5 directory; can this be reduced?
 I'm also not sure if the expected structure is that
resulting from the installed version of the sources or just
the CVS checkout; it's largely the same, but slightly
different at the top (probably not in any relevant way).  It
appears slightly tedious to make this work easily in both
tree structures, since the win32/ directory is not part of
the Source/ directory of the installed Expat package.

I still haven't had time to re-install my Windows
environment, so I can't yet install Borland's free
command-line compiler, so I'll need your guidance.  ;-(

We are getting ready to release Expat 1.95.4 this coming Friday.

Marking this report "pending", awaiting your response.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 21:29

Message:
Logged In: YES 
user_id=3066

Re-opened and assigned to myself.

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

Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-10 19:00

Message:
Logged In: YES 
user_id=415653

Ahh, I didnt clue in that you wanted me to do something 
previously. I have been keeping my proj and makefiles up 
to date and have attached the latest. They should go into 
expat/proj/win32/BCB5 (I did this instead of spreading 
them around the directory tree to reduce clutter).

You can test it with the free Borland command line 
compiler, the make files work with that. 
http://www.borland.com/products/downloads/download_cb
uilder.html

If you are getting close to a release and want to include this 
I'll check it out on a daily basis. Im using the cvs files.

Patrick

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 16:31

Message:
Logged In: YES 
user_id=3066

Closing due to non-responsiveness of the reporter and
generally not being able to bring this up to date.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 18:39

Message:
Logged In: YES 
user_id=3066

Well, I won't be able to install the C++ Builder demo on my Win2K 
system since I don't have enough space on my system disk.  ;-(

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 00:04

Message:
Logged In: YES 
user_id=3066

Does this need to be updated to reflect the header name change from 
"config.h" to "expat_config.h"?

I don't think I'll have time to look at 
this before 1.95.3; is this just a few additional files or do other files need 
changing?  I'll try to install the recent C++ Builder demo to try this out.

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

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


From noreply@sourceforge.net  Thu Jul 11 12:25:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu Jul 11 11:25:05 2002
Subject: [ expat-Patches-538032 ] Borland Win32 project & makefiles
Message-ID: <E17Sibw-0005g6-00@usw-sf-web1.sourceforge.net>

Patches item #538032, was opened at 2002-04-01 16:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=538032&group_id=10127

Category: Build Control
Group: Feature Request
>Status: Pending
Resolution: Out of Date
Priority: 5
Submitted By: Patrick McConnell (pmcconnell)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Borland Win32 project & makefiles

Initial Comment:
Borland C++ Builder project file and make file for the 
command line compiler to build expat.dll

Unzip the patch from the directory above expat, then 
read the README.borland file for instructions.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 14:24

Message:
Logged In: YES 
user_id=3066

Karl:  I like the idea that multiple toolchains can be
supported in one tree, but doubt it's worth the effort or
resulting fragility.  Many tools aren't terribly flexible
about project layout, either.  ;-(

Patrick:  Let's create bcb5 at the top level today, and
place all the project-related files there.  If the output
can go in bcb5\release, that should make it easy enough for
people to work with both Windows compilers in one tree for
now, and we can re-work things in the next release if that
seems to be the right thing.

I can add this as soon as I have a set of files you approve
of.  I'm deleting the older of the packages you provided
since that's so out of date at this point.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 14:01

Message:
Logged In: YES 
user_id=290026

I am wondering if each build target should not have its 
own "release" type directoy? Imagine you want to 
maintain separate builds of Expat under VC6 and BCB5.
In that case it would be nice if they would not overwrite 
each other. But maybe that is too fancy.

Karl

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

Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-11 13:54

Message:
Logged In: YES 
user_id=415653

Why dont I put the BCB files in expat/BCB5. Then the 
make files will be there ready to by integrated into the top 
level make files at a later date. Also, the VC proj's put the 
binaries in various "release" directories but since the BCB 
files are all in one place why dont I just put the binaries in 
expat/win32/release. Finally, should I copy the libs to 
expat/Lib? I can do all this today if you want to include it in 
tomorrows release.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 13:15

Message:
Logged In: YES 
user_id=290026

>  (Karl, any thoughts on moving the .DSP and .DSW
>  files to win32\msvc6 ?)

Well, ideally I would like it symmetrical, i.e. all
the build files for the various targets should be
in separate directories on the same level.

It seems it is not that clear that we should have an extra
level for the OS, since Windows Dlls can be built on 
VC6, BCB5 and Cygwin.

Also, the Make stuff may apply to various OSes 
simultaneously. So, maybe we could have the Make stuff
at the top level, as we already have, and create one
child directory for each build target that needs special
treatment beyond Make. In other words, I am
thinking off a VC6 directory and a BCB5 directory directly
under the top level (I believe you already have a vms 
directory like that).

Karl



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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 13:01

Message:
Logged In: YES 
user_id=3066

Regarding the clean and cleanall targets:  You're right, the
new version of clean you describe would be better, and
"cleanall" should probably be named "distclean", and should
remove everything created in the process of running the
makefile (including DLLs, .LIB files, etc.).

The MSVC project works because the directories it needs are
all arranged the same way for both CVS checkouts and the
"installed" sources.  You might want to look at
win32/MANIFEST.txt; it describes the layout of the installed
package on Windows.  There is no equivalent of the win32
directory in the result; I'd imagined putting the BCB5
directory inside that.  I think I could copy the directory
to Sources\BCB5 using the installer, but that makes it one
level closer to the top of the source tree in the installed
version than in CVS, which breaks the use of ..\.. references.

I like the idea of keeping the project files away from the
actual sources though.  Perhaps I can change the MSVC
projects to work in a similar way, but I'm hesitant to make
so many changes to the structure just before tomorrow's release.

(Karl, any thoughts on moving the .DSP and .DSW files to
win32\msvc6 ?)

Would it be reasonable to adjust the files to work from
win32\bcb5, and only worry about them from CVS for now,
leaving them out of the installer in 1.95.4.  Re-working the
project file layout can be done for 1.95.5, so it can be
given more thought.

Thanks!

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

Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-11 12:31

Message:
Logged In: YES 
user_id=415653

Fred,

The directory structure I used for the project files is copied 
from easysoap and xerces-c. It is more than expat needs 
at this point but if you start getting more and more ports to 
other OS's and build tools it becomes necessary. For 
example, your VC files could go into expat/proj/win32/VC6. 
However, if you like, I can put everything into a directory 
called BCB5 right under the expat root.

cleanall removes the executables, obj files and the build 
directories. Instead of renaming it, I'll just create another 
target called clean that only removes the obj files. I think 
this is more standard. OK?

About the directory structure: I was assuming the cvs is 
the same as the release structure. My build files are now 
set up to put the binaries in "release" directories under the 
various source directories (lib, examples, xmlwf and 
gennmtab). Are you saying the installed directory structure 
has all the source directories under src (or Source)? Also, 
for the release, should all the binaries go into expat/win32? 
I can do this no problem, just let me know.

I got the setup Im using now by translating the VC project 
files into BCB format, so I figured it would be right, but I 
never thought the installed structure would be different 
from the cvs.

Patrick

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 23:02

Message:
Logged In: YES 
user_id=3066

After a quick review:

I'd like to rename the "cleanall" target to simply "clean",
as this is a more common name for this function.

There appear to be many intermediate directories between the
top of the tree and the BCB5 directory; can this be reduced?
 I'm also not sure if the expected structure is that
resulting from the installed version of the sources or just
the CVS checkout; it's largely the same, but slightly
different at the top (probably not in any relevant way).  It
appears slightly tedious to make this work easily in both
tree structures, since the win32/ directory is not part of
the Source/ directory of the installed Expat package.

I still haven't had time to re-install my Windows
environment, so I can't yet install Borland's free
command-line compiler, so I'll need your guidance.  ;-(

We are getting ready to release Expat 1.95.4 this coming Friday.

Marking this report "pending", awaiting your response.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 21:29

Message:
Logged In: YES 
user_id=3066

Re-opened and assigned to myself.

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

Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-10 19:00

Message:
Logged In: YES 
user_id=415653

Ahh, I didnt clue in that you wanted me to do something 
previously. I have been keeping my proj and makefiles up 
to date and have attached the latest. They should go into 
expat/proj/win32/BCB5 (I did this instead of spreading 
them around the directory tree to reduce clutter).

You can test it with the free Borland command line 
compiler, the make files work with that. 
http://www.borland.com/products/downloads/download_cb
uilder.html

If you are getting close to a release and want to include this 
I'll check it out on a daily basis. Im using the cvs files.

Patrick

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 16:31

Message:
Logged In: YES 
user_id=3066

Closing due to non-responsiveness of the reporter and
generally not being able to bring this up to date.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 18:39

Message:
Logged In: YES 
user_id=3066

Well, I won't be able to install the C++ Builder demo on my Win2K 
system since I don't have enough space on my system disk.  ;-(

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 00:04

Message:
Logged In: YES 
user_id=3066

Does this need to be updated to reflect the header name change from 
"config.h" to "expat_config.h"?

I don't think I'll have time to look at 
this before 1.95.3; is this just a few additional files or do other files need 
changing?  I'll try to install the recent C++ Builder demo to try this out.

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

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


From noreply@sourceforge.net  Thu Jul 11 12:57:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu Jul 11 11:57:01 2002
Subject: [ expat-Patches-566901 ] install (if building outside the sourcedir) fails
Message-ID: <E17Sj6u-00017U-00@usw-sf-web3.sourceforge.net>

Patches item #566901, was opened at 2002-06-10 11:30
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=566901&group_id=10127

Category: Build Control
Group: None
>Status: Closed
Resolution: Accepted
Priority: 7
Submitted By: Gerrit Haase (siebenschlaefer)
Assigned to: Gerrit Haase (siebenschlaefer)
Summary: install (if building outside the sourcedir) fails

Initial Comment:
1. It is not possible to build outside the sourcedir.
Starts with wrong paths and after fixing this I get 
problems because expat.h and the manfile were not 
found. e.g. error , please see below.
2. Calling autoconf gives this message:
    conftools/get-version.sh: not found


/usr/bin/install -c 
lib/.libs/libexpat.dll.a /var/www/htdocs/cywgin/ex
pat/test/expat-1.95.3/.inst/usr/lib/libexpat.dll.a
dlpath=`bash 2>&1 -c '. 
lib/.libs/lib/libexpat.lai;echo $dlname'`
 dldir=/var/www/htdocs/cywgin/expat/test/expat-
1.95.3/.inst/usr/lib/`dirname $dlpath`
dirname: too many arguments
Try `dirname --help' for more information.
make: *** [installlib] Error 1


Attached is the diff from my changes to Makefile.in 
to get it to install successfull outside the sourcedir.


Gerrit
-- 
=^..^=

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 14:56

Message:
Logged In: YES 
user_id=3066

Checked in as Makefile.in revision 1.37.  Updated .cvsignore
files as appropriate.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-08 14:02

Message:
Logged In: YES 
user_id=3066

Gerrit: I've tested the new version of the and it works for
me.  Please commit the changes.

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

Comment By: Gerrit Haase (siebenschlaefer)
Date: 2002-06-12 10:44

Message:
Logged In: YES 
user_id=76037

Hi David,

you wrote:
>Gerrit's patch almost works for me. However, I also had
>to change

>  INCLUDES = -Ilib -I.

>to

>  INCLUDES = -I$(srcdir)/lib -I.


you are right.  This is an oversight from me, since I have 
expat already installed in the standard locations I got no 
problems.  This needs to be fixed in my latest package 
which I offered for inclusion to the Cygwin netrelease.

>Moreover, I don't understand the need
>for the docdir macro.  There's no target that uses this, 
>AFAICT.

Yes, also true, this is only used for internal (Cygwin) 
use, we install docs into /usr/doc/${package-name},
I wanted to create the docdir from the make run, but 
never used it. (docs here are including license 
information and the README included in the expat 
source dist.)

I do this with my build script, no need to include it in 
the dist since expat doesn't install docs besides the 
manfile.


Many thanks for your patch review;)

Gerrit
-- 
=^..^=

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

Comment By: Gerrit Haase (siebenschlaefer)
Date: 2002-06-12 10:43

Message:
Logged In: YES 
user_id=76037

Hi David,

you wrote:
>Gerrit's patch almost works for me. However, I also had
>to change

>  INCLUDES = -Ilib -I.

>to

>  INCLUDES = -I$(srcdir)/lib -I.


you are right.  This is an oversight from me, since I have 
expat already installed in the standard locations I got no 
problems.  This needs to be fixed in my latest package 
which I offered for inclusion to the Cygwin netrelease.

>Moreover, I don't understand the need
>for the docdir macro.  There's no target that uses this, 
>AFAICT.

Yes, also true, this is only used for internal (Cygwin) 
use, we install docs into /usr/doc/${package-name},
I wanted to create the docdir from the make run, but 
never used it. (docs here are including license 
information and the README included in the expat 
source dist.)

I do this with my build script, no need to include it in 
the dist since expat doesn't install docs besides the 
manfile.


Many thanks for your patch review;)

Gerrit
-- 
=^..^=

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

Comment By: David Starks-Browning (davidsb)
Date: 2002-06-12 10:06

Message:
Logged In: YES 
user_id=561928

Yes, please do get "make" and "make install" working when building outside the source tree.
I also need it, and not for Cygwin. :-)

Gerrit's patch almost works for me. However, I also had to change

  INCLUDES = -Ilib -I.

to

  INCLUDES = -I$(srcdir)/lib -I.

Gerrit, if you didn't need this, then you probably compiled with whatever expat.h had been installed
in the default location (or as augmented by CPPFLAGS).

Moreover, I don't understand the need
for the docdir macro.  There's no target that uses this, AFAICT.

For the record, I had reported similar problems with 1.95.1 in bug #406262, but had not tracked expat
development since then.

Thanks everyone!

David

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

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


From noreply@sourceforge.net  Thu Jul 11 13:41:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu Jul 11 12:41:08 2002
Subject: [ expat-Bugs-580258 ] Problem with GetBuffer/ParseBuffer
Message-ID: <E17SjoA-0000lG-00@usw-sf-web5.sourceforge.net>

Bugs item #580258, was opened at 2002-07-11 14:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580258&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher M. Woods (cmwoods)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with GetBuffer/ParseBuffer

Initial Comment:
This is my first post so forgive me if I leave anything 
out...
     I've encountered a problem while using the 
XML_GetBuffer/XML_ParserBuffer methods of the Expat 
library.  [Using libexpatw.lib, on Win2K w/ MSVC++ 6.0 -
 sp5, wide chars (UNICODE), with a UTF-16 encoded 
XML file of roughly 33KB of data.]  When using these 
methods, I've experienced errors from the parser stating 
one of the following: not well-formed XML, illegal token, 
or unclosed token.  Each of the errors appear 
consistently for a given file and a given buffer size.
     I haven't narrowed down the problem yet - and will 
include more information once I get a chance to dig into 
the code further.  I can tell you that I get no errors on the 
file if I read it into my own buffer and use the XML_Parse 
method.  I can also tell you that I DO GET errors if I 
request a buffer large enough for the file, read the file 
into the buffer, and then call XML_ParseBuffer... so the 
problem appears to be [at least on the surface] with 
XML_ParseBuffer.

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

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


From noreply@sourceforge.net  Thu Jul 11 13:52:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu Jul 11 12:52:05 2002
Subject: [ expat-Bugs-580258 ] Problem with GetBuffer/ParseBuffer
Message-ID: <E17Sjyp-0001jj-00@usw-sf-web4.sourceforge.net>

Bugs item #580258, was opened at 2002-07-11 15:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580258&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher M. Woods (cmwoods)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with GetBuffer/ParseBuffer

Initial Comment:
This is my first post so forgive me if I leave anything 
out...
     I've encountered a problem while using the 
XML_GetBuffer/XML_ParserBuffer methods of the Expat 
library.  [Using libexpatw.lib, on Win2K w/ MSVC++ 6.0 -
 sp5, wide chars (UNICODE), with a UTF-16 encoded 
XML file of roughly 33KB of data.]  When using these 
methods, I've experienced errors from the parser stating 
one of the following: not well-formed XML, illegal token, 
or unclosed token.  Each of the errors appear 
consistently for a given file and a given buffer size.
     I haven't narrowed down the problem yet - and will 
include more information once I get a chance to dig into 
the code further.  I can tell you that I get no errors on the 
file if I read it into my own buffer and use the XML_Parse 
method.  I can also tell you that I DO GET errors if I 
request a buffer large enough for the file, read the file 
into the buffer, and then call XML_ParseBuffer... so the 
problem appears to be [at least on the surface] with 
XML_ParseBuffer.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 15:51

Message:
Logged In: YES 
user_id=3066

Are you using Expat 1.95.3 or the CVS version of Expat?

If you're not using the CVS version, can you take a look at
that version and try to reproduce the problem?  You can get
information on getting the CVS version anonymously at:

http://www.libexpat.org/dev/cvs.html

Thanks!

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

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


From noreply@sourceforge.net  Thu Jul 11 14:02:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu Jul 11 13:02:03 2002
Subject: [ expat-Bugs-580258 ] Problem with GetBuffer/ParseBuffer
Message-ID: <E17Sk81-0007il-00@usw-sf-web1.sourceforge.net>

Bugs item #580258, was opened at 2002-07-11 15:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580258&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher M. Woods (cmwoods)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with GetBuffer/ParseBuffer

Initial Comment:
This is my first post so forgive me if I leave anything 
out...
     I've encountered a problem while using the 
XML_GetBuffer/XML_ParserBuffer methods of the Expat 
library.  [Using libexpatw.lib, on Win2K w/ MSVC++ 6.0 -
 sp5, wide chars (UNICODE), with a UTF-16 encoded 
XML file of roughly 33KB of data.]  When using these 
methods, I've experienced errors from the parser stating 
one of the following: not well-formed XML, illegal token, 
or unclosed token.  Each of the errors appear 
consistently for a given file and a given buffer size.
     I haven't narrowed down the problem yet - and will 
include more information once I get a chance to dig into 
the code further.  I can tell you that I get no errors on the 
file if I read it into my own buffer and use the XML_Parse 
method.  I can also tell you that I DO GET errors if I 
request a buffer large enough for the file, read the file 
into the buffer, and then call XML_ParseBuffer... so the 
problem appears to be [at least on the surface] with 
XML_ParseBuffer.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 16:01

Message:
Logged In: YES 
user_id=290026

Would you mind attaching the file and giving me the 
buffer size you used?
I will try to duplicate the problem.

Karl

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 15:51

Message:
Logged In: YES 
user_id=3066

Are you using Expat 1.95.3 or the CVS version of Expat?

If you're not using the CVS version, can you take a look at
that version and try to reproduce the problem?  You can get
information on getting the CVS version anonymously at:

http://www.libexpat.org/dev/cvs.html

Thanks!

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

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


From noreply@sourceforge.net  Thu Jul 11 15:52:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu Jul 11 14:52:07 2002
Subject: [ expat-Bugs-580258 ] Problem with GetBuffer/ParseBuffer
Message-ID: <E17Slqc-0003E4-00@usw-sf-web5.sourceforge.net>

Bugs item #580258, was opened at 2002-07-11 14:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580258&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher M. Woods (cmwoods)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with GetBuffer/ParseBuffer

Initial Comment:
This is my first post so forgive me if I leave anything 
out...
     I've encountered a problem while using the 
XML_GetBuffer/XML_ParserBuffer methods of the Expat 
library.  [Using libexpatw.lib, on Win2K w/ MSVC++ 6.0 -
 sp5, wide chars (UNICODE), with a UTF-16 encoded 
XML file of roughly 33KB of data.]  When using these 
methods, I've experienced errors from the parser stating 
one of the following: not well-formed XML, illegal token, 
or unclosed token.  Each of the errors appear 
consistently for a given file and a given buffer size.
     I haven't narrowed down the problem yet - and will 
include more information once I get a chance to dig into 
the code further.  I can tell you that I get no errors on the 
file if I read it into my own buffer and use the XML_Parse 
method.  I can also tell you that I DO GET errors if I 
request a buffer large enough for the file, read the file 
into the buffer, and then call XML_ParseBuffer... so the 
problem appears to be [at least on the surface] with 
XML_ParseBuffer.

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

>Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-11 16:51

Message:
Logged In: YES 
user_id=576763

Frank,
   I was/am using the 1.95.3 version of the project.  I'll try the 
CVS version when I get a chance (very busy).

Karl,
   I've attached the sample file that I was using/having 
problems with.  I tried several buffer sizes including: 32768, 
65536, 1000000, and (if I remember correctly) 8192.

Thanks,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 15:01

Message:
Logged In: YES 
user_id=290026

Would you mind attaching the file and giving me the 
buffer size you used?
I will try to duplicate the problem.

Karl

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 14:51

Message:
Logged In: YES 
user_id=3066

Are you using Expat 1.95.3 or the CVS version of Expat?

If you're not using the CVS version, can you take a look at
that version and try to reproduce the problem?  You can get
information on getting the CVS version anonymously at:

http://www.libexpat.org/dev/cvs.html

Thanks!

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

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


From noreply@sourceforge.net  Thu Jul 11 19:23:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu Jul 11 18:23:02 2002
Subject: [ expat-Bugs-580258 ] Problem with GetBuffer/ParseBuffer
Message-ID: <E17Sp8h-0006nw-00@usw-sf-web5.sourceforge.net>

Bugs item #580258, was opened at 2002-07-11 15:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580258&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher M. Woods (cmwoods)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with GetBuffer/ParseBuffer

Initial Comment:
This is my first post so forgive me if I leave anything 
out...
     I've encountered a problem while using the 
XML_GetBuffer/XML_ParserBuffer methods of the Expat 
library.  [Using libexpatw.lib, on Win2K w/ MSVC++ 6.0 -
 sp5, wide chars (UNICODE), with a UTF-16 encoded 
XML file of roughly 33KB of data.]  When using these 
methods, I've experienced errors from the parser stating 
one of the following: not well-formed XML, illegal token, 
or unclosed token.  Each of the errors appear 
consistently for a given file and a given buffer size.
     I haven't narrowed down the problem yet - and will 
include more information once I get a chance to dig into 
the code further.  I can tell you that I get no errors on the 
file if I read it into my own buffer and use the XML_Parse 
method.  I can also tell you that I DO GET errors if I 
request a buffer large enough for the file, read the file 
into the buffer, and then call XML_ParseBuffer... so the 
problem appears to be [at least on the surface] with 
XML_ParseBuffer.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 21:22

Message:
Logged In: YES 
user_id=290026

I cannot reproduce your problem with the current CVS
and also not with 1.95.3. I tested with the same buffer sizes 
you gave me.

I compiled the Dll with VC++6 (I believe I have SP5 also).
My test program is written in Delphi, but you can probably
still compare my parsing loop with yours:

const
  XML_READBUFSIZE = 65536;
...
IsFinal := False;
while not IsFinal do
  begin
  Buffer := XMLGetBuffer(Parser, XML_READBUFSIZE);
  if Buffer = nil then OutOfMemoryError;
  ReadCount := Stream.Read(Buffer^, XML_READBUFSIZE);
  IsFinal := ReadCount < XML_READBUFSIZE;
  if XMLParseBuffer(Parser, ReadCount, Integer(IsFinal)) = 0 
then
    begin
    ErrorCode := Ord(XMLGetErrorCode(Parser));
    ...
    Break;
    end;
  end;

Is that different?

Karl



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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-11 17:51

Message:
Logged In: YES 
user_id=576763

Frank,
   I was/am using the 1.95.3 version of the project.  I'll try the 
CVS version when I get a chance (very busy).

Karl,
   I've attached the sample file that I was using/having 
problems with.  I tried several buffer sizes including: 32768, 
65536, 1000000, and (if I remember correctly) 8192.

Thanks,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 16:01

Message:
Logged In: YES 
user_id=290026

Would you mind attaching the file and giving me the 
buffer size you used?
I will try to duplicate the problem.

Karl

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 15:51

Message:
Logged In: YES 
user_id=3066

Are you using Expat 1.95.3 or the CVS version of Expat?

If you're not using the CVS version, can you take a look at
that version and try to reproduce the problem?  You can get
information on getting the CVS version anonymously at:

http://www.libexpat.org/dev/cvs.html

Thanks!

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

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


From noreply@sourceforge.net  Thu Jul 11 20:51:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu Jul 11 19:51:03 2002
Subject: [ expat-Patches-538032 ] Borland Win32 project & makefiles
Message-ID: <E17SqVc-0008IK-00@usw-sf-web3.sourceforge.net>

Patches item #538032, was opened at 2002-04-01 16:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=538032&group_id=10127

Category: Build Control
Group: Feature Request
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Patrick McConnell (pmcconnell)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Borland Win32 project & makefiles

Initial Comment:
Borland C++ Builder project file and make file for the 
command line compiler to build expat.dll

Unzip the patch from the directory above expat, then 
read the README.borland file for instructions.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 22:50

Message:
Logged In: YES 
user_id=3066

The version Patrick sent to me in email, based on the
discussion in the comments on this report, has been checked
in for inclusion in Expat 1.95.4.

Thanks, Patrick!

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 14:24

Message:
Logged In: YES 
user_id=3066

Karl:  I like the idea that multiple toolchains can be
supported in one tree, but doubt it's worth the effort or
resulting fragility.  Many tools aren't terribly flexible
about project layout, either.  ;-(

Patrick:  Let's create bcb5 at the top level today, and
place all the project-related files there.  If the output
can go in bcb5\release, that should make it easy enough for
people to work with both Windows compilers in one tree for
now, and we can re-work things in the next release if that
seems to be the right thing.

I can add this as soon as I have a set of files you approve
of.  I'm deleting the older of the packages you provided
since that's so out of date at this point.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 14:01

Message:
Logged In: YES 
user_id=290026

I am wondering if each build target should not have its 
own "release" type directoy? Imagine you want to 
maintain separate builds of Expat under VC6 and BCB5.
In that case it would be nice if they would not overwrite 
each other. But maybe that is too fancy.

Karl

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

Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-11 13:54

Message:
Logged In: YES 
user_id=415653

Why dont I put the BCB files in expat/BCB5. Then the 
make files will be there ready to by integrated into the top 
level make files at a later date. Also, the VC proj's put the 
binaries in various "release" directories but since the BCB 
files are all in one place why dont I just put the binaries in 
expat/win32/release. Finally, should I copy the libs to 
expat/Lib? I can do all this today if you want to include it in 
tomorrows release.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 13:15

Message:
Logged In: YES 
user_id=290026

>  (Karl, any thoughts on moving the .DSP and .DSW
>  files to win32\msvc6 ?)

Well, ideally I would like it symmetrical, i.e. all
the build files for the various targets should be
in separate directories on the same level.

It seems it is not that clear that we should have an extra
level for the OS, since Windows Dlls can be built on 
VC6, BCB5 and Cygwin.

Also, the Make stuff may apply to various OSes 
simultaneously. So, maybe we could have the Make stuff
at the top level, as we already have, and create one
child directory for each build target that needs special
treatment beyond Make. In other words, I am
thinking off a VC6 directory and a BCB5 directory directly
under the top level (I believe you already have a vms 
directory like that).

Karl



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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 13:01

Message:
Logged In: YES 
user_id=3066

Regarding the clean and cleanall targets:  You're right, the
new version of clean you describe would be better, and
"cleanall" should probably be named "distclean", and should
remove everything created in the process of running the
makefile (including DLLs, .LIB files, etc.).

The MSVC project works because the directories it needs are
all arranged the same way for both CVS checkouts and the
"installed" sources.  You might want to look at
win32/MANIFEST.txt; it describes the layout of the installed
package on Windows.  There is no equivalent of the win32
directory in the result; I'd imagined putting the BCB5
directory inside that.  I think I could copy the directory
to Sources\BCB5 using the installer, but that makes it one
level closer to the top of the source tree in the installed
version than in CVS, which breaks the use of ..\.. references.

I like the idea of keeping the project files away from the
actual sources though.  Perhaps I can change the MSVC
projects to work in a similar way, but I'm hesitant to make
so many changes to the structure just before tomorrow's release.

(Karl, any thoughts on moving the .DSP and .DSW files to
win32\msvc6 ?)

Would it be reasonable to adjust the files to work from
win32\bcb5, and only worry about them from CVS for now,
leaving them out of the installer in 1.95.4.  Re-working the
project file layout can be done for 1.95.5, so it can be
given more thought.

Thanks!

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

Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-11 12:31

Message:
Logged In: YES 
user_id=415653

Fred,

The directory structure I used for the project files is copied 
from easysoap and xerces-c. It is more than expat needs 
at this point but if you start getting more and more ports to 
other OS's and build tools it becomes necessary. For 
example, your VC files could go into expat/proj/win32/VC6. 
However, if you like, I can put everything into a directory 
called BCB5 right under the expat root.

cleanall removes the executables, obj files and the build 
directories. Instead of renaming it, I'll just create another 
target called clean that only removes the obj files. I think 
this is more standard. OK?

About the directory structure: I was assuming the cvs is 
the same as the release structure. My build files are now 
set up to put the binaries in "release" directories under the 
various source directories (lib, examples, xmlwf and 
gennmtab). Are you saying the installed directory structure 
has all the source directories under src (or Source)? Also, 
for the release, should all the binaries go into expat/win32? 
I can do this no problem, just let me know.

I got the setup Im using now by translating the VC project 
files into BCB format, so I figured it would be right, but I 
never thought the installed structure would be different 
from the cvs.

Patrick

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 23:02

Message:
Logged In: YES 
user_id=3066

After a quick review:

I'd like to rename the "cleanall" target to simply "clean",
as this is a more common name for this function.

There appear to be many intermediate directories between the
top of the tree and the BCB5 directory; can this be reduced?
 I'm also not sure if the expected structure is that
resulting from the installed version of the sources or just
the CVS checkout; it's largely the same, but slightly
different at the top (probably not in any relevant way).  It
appears slightly tedious to make this work easily in both
tree structures, since the win32/ directory is not part of
the Source/ directory of the installed Expat package.

I still haven't had time to re-install my Windows
environment, so I can't yet install Borland's free
command-line compiler, so I'll need your guidance.  ;-(

We are getting ready to release Expat 1.95.4 this coming Friday.

Marking this report "pending", awaiting your response.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-10 21:29

Message:
Logged In: YES 
user_id=3066

Re-opened and assigned to myself.

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

Comment By: Patrick McConnell (pmcconnell)
Date: 2002-07-10 19:00

Message:
Logged In: YES 
user_id=415653

Ahh, I didnt clue in that you wanted me to do something 
previously. I have been keeping my proj and makefiles up 
to date and have attached the latest. They should go into 
expat/proj/win32/BCB5 (I did this instead of spreading 
them around the directory tree to reduce clutter).

You can test it with the free Borland command line 
compiler, the make files work with that. 
http://www.borland.com/products/downloads/download_cb
uilder.html

If you are getting close to a release and want to include this 
I'll check it out on a daily basis. Im using the cvs files.

Patrick

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 16:31

Message:
Logged In: YES 
user_id=3066

Closing due to non-responsiveness of the reporter and
generally not being able to bring this up to date.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 18:39

Message:
Logged In: YES 
user_id=3066

Well, I won't be able to install the C++ Builder demo on my Win2K 
system since I don't have enough space on my system disk.  ;-(

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 00:04

Message:
Logged In: YES 
user_id=3066

Does this need to be updated to reflect the header name change from 
"config.h" to "expat_config.h"?

I don't think I'll have time to look at 
this before 1.95.3; is this just a few additional files or do other files need 
changing?  I'll try to install the recent C++ Builder demo to try this out.

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

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


From noreply@sourceforge.net  Fri Jul 12 03:48:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 02:48:05 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17Sx1b-00063d-00@usw-sf-web4.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 04:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ari Johnson (ari_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

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


From noreply@sourceforge.net  Fri Jul 12 06:10:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 05:10:06 2002
Subject: [ expat-Patches-458907 ] config.h appears to be unused
Message-ID: <E17SzEU-0000nE-00@usw-sf-web4.sourceforge.net>

Patches item #458907, was opened at 2001-09-05 17:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=458907&group_id=10127

Category: Build Control
Group: None
>Status: Open
>Resolution: Out of Date
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Greg Stein (gstein)
Summary: config.h appears to be unused

Initial Comment:
To compile expat as part of another package (e.g. 
PyXML), the expat configure might not have been run. 
For that kind of application, it is necessary to wrap 
each occurrence of config.h into HAVE_CONFIG_H; the 
attached patch does that.

While trying to figure out which of the defines are 
needed, it appears that none of them are (i.e. HAVE_ 
is never used). For stand-along compilation, I found 
that only VERSION, XML_NS, XML_DTD, XML_BYTE_ORDER, 
and XML_CONTEXT_BYTES must be defined. Is that 
impression correct?


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-12 08:09

Message:
Logged In: YES 
user_id=3066

This has come up as still being a problem for a couple of 
projects on the Python XML-SIG, so this needs to be 
reconsidered.

Hopefully Martin will be interested in checking and updating 
his proposed patch against 1.95.4.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 05:15

Message:
Logged In: YES 
user_id=21627

Can you elaborate which defines of  expat_config.h is used
in xmlwf? I could not find any.

Why is it wrong to not run configure? autoconf packages,
historically, always supported "manual" configuration, by
editing config.h manually. Also,  your own build process
does not use expat_config.h if COMPILED_FROM_DSP is set. In
general, it is not possible to run configure if you don't
have /bin/sh on a system; this is a scenario that PyXML
needs to support.

Also, traditionally, autoconf supports both configuration
with and without a config.h; files including config.h would
always wrap this with a

#ifdef HAVE_CONFIG_H

(should be HAVE_EXPAT_CONFIG_H in your case).

All I'm asking is that the combination "manual
configuration" and "no config.h" is supported. If this is
not available, I have to fake-generate a config.h, which is
ugly.

It would also help if config.h was reduced to the set of
defines which are actually used, instead of autoconfiscating
every line of the source.

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

Comment By: Greg Stein (gstein)
Date: 2002-06-01 19:44

Message:
Logged In: YES 
user_id=6501

We may not use most of those (autoconf creates them as part
of searching for particular functions and stuff), but xmlwf
does use some.

That said: if you're going to embed Expat into another
application, then you'll need to adjust things accordingly.
Note that we've switched to "expat_config.h", so it might be
possible to just include that into your own application
since a conflict on config.h won't occur any more.

Also, note that the premise of "not running configure" is
probably quite wrong. Expat is embedded into the ASF's
apr-util project, and we *do* run configure for that, and
build expat as a sub-library. (heck, we even run expat's
buildconf.sh at the appropriate time)

Given the change to expat_config.h, and how I believe
embedding should work, I'm going to close this patch as
rejected. However, even with that said, I'm quite happy to
be corrected and/or to make other changes to simplify
Expat's ability to be embedded.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 00:10

Message:
Logged In: YES 
user_id=3066

Greg, can you please respond to this?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-11-08 23:48

Message:
Logged In: YES 
user_id=3066

It certainly looks like it can be reduced and possibly
removed; I'll read up on a few of the autoconf things before
removing it completely.

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

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


From noreply@sourceforge.net  Fri Jul 12 06:53:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 05:53:08 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17Sztx-0001eQ-00@usw-sf-web4.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 05:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ari Johnson (ari_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

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


From noreply@sourceforge.net  Fri Jul 12 07:08:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 06:08:12 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17T08z-0002h3-00@usw-sf-web5.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 05:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ari Johnson (ari_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 09:07

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

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


From noreply@sourceforge.net  Fri Jul 12 07:42:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 06:42:05 2002
Subject: [ expat-Bugs-580258 ] Problem with GetBuffer/ParseBuffer
Message-ID: <E17T0fv-0001KB-00@usw-sf-web3.sourceforge.net>

Bugs item #580258, was opened at 2002-07-11 14:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580258&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher M. Woods (cmwoods)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with GetBuffer/ParseBuffer

Initial Comment:
This is my first post so forgive me if I leave anything 
out...
     I've encountered a problem while using the 
XML_GetBuffer/XML_ParserBuffer methods of the Expat 
library.  [Using libexpatw.lib, on Win2K w/ MSVC++ 6.0 -
 sp5, wide chars (UNICODE), with a UTF-16 encoded 
XML file of roughly 33KB of data.]  When using these 
methods, I've experienced errors from the parser stating 
one of the following: not well-formed XML, illegal token, 
or unclosed token.  Each of the errors appear 
consistently for a given file and a given buffer size.
     I haven't narrowed down the problem yet - and will 
include more information once I get a chance to dig into 
the code further.  I can tell you that I get no errors on the 
file if I read it into my own buffer and use the XML_Parse 
method.  I can also tell you that I DO GET errors if I 
request a buffer large enough for the file, read the file 
into the buffer, and then call XML_ParseBuffer... so the 
problem appears to be [at least on the surface] with 
XML_ParseBuffer.

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

>Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 08:41

Message:
Logged In: YES 
user_id=576763

   Hmm... Perhaps I'm missing something in my setup or the 
delphi code isn't quite the same?  I'm using wchar_t 
(UNICODE & _UNICODE defines) and maybe the issue is 
related to that?  I've included a sample project in the zip file 
that exhibits the behaviorism that I'm seeing.
   The libexpatw.lib is right from the win32bin distribution 
(1.95.3) and the libexpatw_d.lib is a debug build I made from 
the included source code.
   If you look in XMLExtractor.cpp, in the Process() function, 
starting at line 52, you'll see both methodologies are coded 
and one is commented out.  The GetBuffer/ParseBuffer 
method fails for me and the Parse method (the 2nd one) 
seems to work fine.  [Separate question: Why does 
XML_Parse take const char* and not XML_Char*?]
   I'd be perfectly happy if this turns out to be nothing more 
that a simple configuration problem on my part.  But I'm 
curious why it seems to work fine one way and not the other.

Thank you for your time,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 20:22

Message:
Logged In: YES 
user_id=290026

I cannot reproduce your problem with the current CVS
and also not with 1.95.3. I tested with the same buffer sizes 
you gave me.

I compiled the Dll with VC++6 (I believe I have SP5 also).
My test program is written in Delphi, but you can probably
still compare my parsing loop with yours:

const
  XML_READBUFSIZE = 65536;
...
IsFinal := False;
while not IsFinal do
  begin
  Buffer := XMLGetBuffer(Parser, XML_READBUFSIZE);
  if Buffer = nil then OutOfMemoryError;
  ReadCount := Stream.Read(Buffer^, XML_READBUFSIZE);
  IsFinal := ReadCount < XML_READBUFSIZE;
  if XMLParseBuffer(Parser, ReadCount, Integer(IsFinal)) = 0 
then
    begin
    ErrorCode := Ord(XMLGetErrorCode(Parser));
    ...
    Break;
    end;
  end;

Is that different?

Karl



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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-11 16:51

Message:
Logged In: YES 
user_id=576763

Frank,
   I was/am using the 1.95.3 version of the project.  I'll try the 
CVS version when I get a chance (very busy).

Karl,
   I've attached the sample file that I was using/having 
problems with.  I tried several buffer sizes including: 32768, 
65536, 1000000, and (if I remember correctly) 8192.

Thanks,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 15:01

Message:
Logged In: YES 
user_id=290026

Would you mind attaching the file and giving me the 
buffer size you used?
I will try to duplicate the problem.

Karl

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 14:51

Message:
Logged In: YES 
user_id=3066

Are you using Expat 1.95.3 or the CVS version of Expat?

If you're not using the CVS version, can you take a look at
that version and try to reproduce the problem?  You can get
information on getting the CVS version anonymously at:

http://www.libexpat.org/dev/cvs.html

Thanks!

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

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


From noreply@sourceforge.net  Fri Jul 12 08:10:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 07:10:07 2002
Subject: [ expat-Bugs-580258 ] Problem with GetBuffer/ParseBuffer
Message-ID: <E17T16j-0004FD-00@usw-sf-web5.sourceforge.net>

Bugs item #580258, was opened at 2002-07-11 15:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580258&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher M. Woods (cmwoods)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with GetBuffer/ParseBuffer

Initial Comment:
This is my first post so forgive me if I leave anything 
out...
     I've encountered a problem while using the 
XML_GetBuffer/XML_ParserBuffer methods of the Expat 
library.  [Using libexpatw.lib, on Win2K w/ MSVC++ 6.0 -
 sp5, wide chars (UNICODE), with a UTF-16 encoded 
XML file of roughly 33KB of data.]  When using these 
methods, I've experienced errors from the parser stating 
one of the following: not well-formed XML, illegal token, 
or unclosed token.  Each of the errors appear 
consistently for a given file and a given buffer size.
     I haven't narrowed down the problem yet - and will 
include more information once I get a chance to dig into 
the code further.  I can tell you that I get no errors on the 
file if I read it into my own buffer and use the XML_Parse 
method.  I can also tell you that I DO GET errors if I 
request a buffer large enough for the file, read the file 
into the buffer, and then call XML_ParseBuffer... so the 
problem appears to be [at least on the surface] with 
XML_ParseBuffer.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 10:09

Message:
Logged In: YES 
user_id=290026

I can't see your zip file.

Karl

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 09:41

Message:
Logged In: YES 
user_id=576763

   Hmm... Perhaps I'm missing something in my setup or the 
delphi code isn't quite the same?  I'm using wchar_t 
(UNICODE & _UNICODE defines) and maybe the issue is 
related to that?  I've included a sample project in the zip file 
that exhibits the behaviorism that I'm seeing.
   The libexpatw.lib is right from the win32bin distribution 
(1.95.3) and the libexpatw_d.lib is a debug build I made from 
the included source code.
   If you look in XMLExtractor.cpp, in the Process() function, 
starting at line 52, you'll see both methodologies are coded 
and one is commented out.  The GetBuffer/ParseBuffer 
method fails for me and the Parse method (the 2nd one) 
seems to work fine.  [Separate question: Why does 
XML_Parse take const char* and not XML_Char*?]
   I'd be perfectly happy if this turns out to be nothing more 
that a simple configuration problem on my part.  But I'm 
curious why it seems to work fine one way and not the other.

Thank you for your time,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 21:22

Message:
Logged In: YES 
user_id=290026

I cannot reproduce your problem with the current CVS
and also not with 1.95.3. I tested with the same buffer sizes 
you gave me.

I compiled the Dll with VC++6 (I believe I have SP5 also).
My test program is written in Delphi, but you can probably
still compare my parsing loop with yours:

const
  XML_READBUFSIZE = 65536;
...
IsFinal := False;
while not IsFinal do
  begin
  Buffer := XMLGetBuffer(Parser, XML_READBUFSIZE);
  if Buffer = nil then OutOfMemoryError;
  ReadCount := Stream.Read(Buffer^, XML_READBUFSIZE);
  IsFinal := ReadCount < XML_READBUFSIZE;
  if XMLParseBuffer(Parser, ReadCount, Integer(IsFinal)) = 0 
then
    begin
    ErrorCode := Ord(XMLGetErrorCode(Parser));
    ...
    Break;
    end;
  end;

Is that different?

Karl



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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-11 17:51

Message:
Logged In: YES 
user_id=576763

Frank,
   I was/am using the 1.95.3 version of the project.  I'll try the 
CVS version when I get a chance (very busy).

Karl,
   I've attached the sample file that I was using/having 
problems with.  I tried several buffer sizes including: 32768, 
65536, 1000000, and (if I remember correctly) 8192.

Thanks,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 16:01

Message:
Logged In: YES 
user_id=290026

Would you mind attaching the file and giving me the 
buffer size you used?
I will try to duplicate the problem.

Karl

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 15:51

Message:
Logged In: YES 
user_id=3066

Are you using Expat 1.95.3 or the CVS version of Expat?

If you're not using the CVS version, can you take a look at
that version and try to reproduce the problem?  You can get
information on getting the CVS version anonymously at:

http://www.libexpat.org/dev/cvs.html

Thanks!

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

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


From noreply@sourceforge.net  Fri Jul 12 08:57:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 07:57:09 2002
Subject: [ expat-Bugs-580258 ] Problem with GetBuffer/ParseBuffer
Message-ID: <E17T1qQ-0006SY-00@usw-sf-web2.sourceforge.net>

Bugs item #580258, was opened at 2002-07-11 14:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580258&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher M. Woods (cmwoods)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with GetBuffer/ParseBuffer

Initial Comment:
This is my first post so forgive me if I leave anything 
out...
     I've encountered a problem while using the 
XML_GetBuffer/XML_ParserBuffer methods of the Expat 
library.  [Using libexpatw.lib, on Win2K w/ MSVC++ 6.0 -
 sp5, wide chars (UNICODE), with a UTF-16 encoded 
XML file of roughly 33KB of data.]  When using these 
methods, I've experienced errors from the parser stating 
one of the following: not well-formed XML, illegal token, 
or unclosed token.  Each of the errors appear 
consistently for a given file and a given buffer size.
     I haven't narrowed down the problem yet - and will 
include more information once I get a chance to dig into 
the code further.  I can tell you that I get no errors on the 
file if I read it into my own buffer and use the XML_Parse 
method.  I can also tell you that I DO GET errors if I 
request a buffer large enough for the file, read the file 
into the buffer, and then call XML_ParseBuffer... so the 
problem appears to be [at least on the surface] with 
XML_ParseBuffer.

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

>Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 09:56

Message:
Logged In: YES 
user_id=576763

Hmm... I'll try again.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 09:09

Message:
Logged In: YES 
user_id=290026

I can't see your zip file.

Karl

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 08:41

Message:
Logged In: YES 
user_id=576763

   Hmm... Perhaps I'm missing something in my setup or the 
delphi code isn't quite the same?  I'm using wchar_t 
(UNICODE & _UNICODE defines) and maybe the issue is 
related to that?  I've included a sample project in the zip file 
that exhibits the behaviorism that I'm seeing.
   The libexpatw.lib is right from the win32bin distribution 
(1.95.3) and the libexpatw_d.lib is a debug build I made from 
the included source code.
   If you look in XMLExtractor.cpp, in the Process() function, 
starting at line 52, you'll see both methodologies are coded 
and one is commented out.  The GetBuffer/ParseBuffer 
method fails for me and the Parse method (the 2nd one) 
seems to work fine.  [Separate question: Why does 
XML_Parse take const char* and not XML_Char*?]
   I'd be perfectly happy if this turns out to be nothing more 
that a simple configuration problem on my part.  But I'm 
curious why it seems to work fine one way and not the other.

Thank you for your time,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 20:22

Message:
Logged In: YES 
user_id=290026

I cannot reproduce your problem with the current CVS
and also not with 1.95.3. I tested with the same buffer sizes 
you gave me.

I compiled the Dll with VC++6 (I believe I have SP5 also).
My test program is written in Delphi, but you can probably
still compare my parsing loop with yours:

const
  XML_READBUFSIZE = 65536;
...
IsFinal := False;
while not IsFinal do
  begin
  Buffer := XMLGetBuffer(Parser, XML_READBUFSIZE);
  if Buffer = nil then OutOfMemoryError;
  ReadCount := Stream.Read(Buffer^, XML_READBUFSIZE);
  IsFinal := ReadCount < XML_READBUFSIZE;
  if XMLParseBuffer(Parser, ReadCount, Integer(IsFinal)) = 0 
then
    begin
    ErrorCode := Ord(XMLGetErrorCode(Parser));
    ...
    Break;
    end;
  end;

Is that different?

Karl



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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-11 16:51

Message:
Logged In: YES 
user_id=576763

Frank,
   I was/am using the 1.95.3 version of the project.  I'll try the 
CVS version when I get a chance (very busy).

Karl,
   I've attached the sample file that I was using/having 
problems with.  I tried several buffer sizes including: 32768, 
65536, 1000000, and (if I remember correctly) 8192.

Thanks,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 15:01

Message:
Logged In: YES 
user_id=290026

Would you mind attaching the file and giving me the 
buffer size you used?
I will try to duplicate the problem.

Karl

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 14:51

Message:
Logged In: YES 
user_id=3066

Are you using Expat 1.95.3 or the CVS version of Expat?

If you're not using the CVS version, can you take a look at
that version and try to reproduce the problem?  You can get
information on getting the CVS version anonymously at:

http://www.libexpat.org/dev/cvs.html

Thanks!

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

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


From noreply@sourceforge.net  Fri Jul 12 09:00:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 08:00:16 2002
Subject: [ expat-Bugs-580258 ] Problem with GetBuffer/ParseBuffer
Message-ID: <E17T1tl-0004eM-00@usw-sf-web4.sourceforge.net>

Bugs item #580258, was opened at 2002-07-11 14:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580258&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher M. Woods (cmwoods)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with GetBuffer/ParseBuffer

Initial Comment:
This is my first post so forgive me if I leave anything 
out...
     I've encountered a problem while using the 
XML_GetBuffer/XML_ParserBuffer methods of the Expat 
library.  [Using libexpatw.lib, on Win2K w/ MSVC++ 6.0 -
 sp5, wide chars (UNICODE), with a UTF-16 encoded 
XML file of roughly 33KB of data.]  When using these 
methods, I've experienced errors from the parser stating 
one of the following: not well-formed XML, illegal token, 
or unclosed token.  Each of the errors appear 
consistently for a given file and a given buffer size.
     I haven't narrowed down the problem yet - and will 
include more information once I get a chance to dig into 
the code further.  I can tell you that I get no errors on the 
file if I read it into my own buffer and use the XML_Parse 
method.  I can also tell you that I DO GET errors if I 
request a buffer large enough for the file, read the file 
into the buffer, and then call XML_ParseBuffer... so the 
problem appears to be [at least on the surface] with 
XML_ParseBuffer.

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

>Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 09:59

Message:
Logged In: YES 
user_id=576763

File was too large... I had to remove libexpatw_d.dll... you'll 
want to rebuild or change project settings to link to 
libexpatw.dll (for debug)

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 09:56

Message:
Logged In: YES 
user_id=576763

Hmm... I'll try again.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 09:09

Message:
Logged In: YES 
user_id=290026

I can't see your zip file.

Karl

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 08:41

Message:
Logged In: YES 
user_id=576763

   Hmm... Perhaps I'm missing something in my setup or the 
delphi code isn't quite the same?  I'm using wchar_t 
(UNICODE & _UNICODE defines) and maybe the issue is 
related to that?  I've included a sample project in the zip file 
that exhibits the behaviorism that I'm seeing.
   The libexpatw.lib is right from the win32bin distribution 
(1.95.3) and the libexpatw_d.lib is a debug build I made from 
the included source code.
   If you look in XMLExtractor.cpp, in the Process() function, 
starting at line 52, you'll see both methodologies are coded 
and one is commented out.  The GetBuffer/ParseBuffer 
method fails for me and the Parse method (the 2nd one) 
seems to work fine.  [Separate question: Why does 
XML_Parse take const char* and not XML_Char*?]
   I'd be perfectly happy if this turns out to be nothing more 
that a simple configuration problem on my part.  But I'm 
curious why it seems to work fine one way and not the other.

Thank you for your time,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 20:22

Message:
Logged In: YES 
user_id=290026

I cannot reproduce your problem with the current CVS
and also not with 1.95.3. I tested with the same buffer sizes 
you gave me.

I compiled the Dll with VC++6 (I believe I have SP5 also).
My test program is written in Delphi, but you can probably
still compare my parsing loop with yours:

const
  XML_READBUFSIZE = 65536;
...
IsFinal := False;
while not IsFinal do
  begin
  Buffer := XMLGetBuffer(Parser, XML_READBUFSIZE);
  if Buffer = nil then OutOfMemoryError;
  ReadCount := Stream.Read(Buffer^, XML_READBUFSIZE);
  IsFinal := ReadCount < XML_READBUFSIZE;
  if XMLParseBuffer(Parser, ReadCount, Integer(IsFinal)) = 0 
then
    begin
    ErrorCode := Ord(XMLGetErrorCode(Parser));
    ...
    Break;
    end;
  end;

Is that different?

Karl



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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-11 16:51

Message:
Logged In: YES 
user_id=576763

Frank,
   I was/am using the 1.95.3 version of the project.  I'll try the 
CVS version when I get a chance (very busy).

Karl,
   I've attached the sample file that I was using/having 
problems with.  I tried several buffer sizes including: 32768, 
65536, 1000000, and (if I remember correctly) 8192.

Thanks,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 15:01

Message:
Logged In: YES 
user_id=290026

Would you mind attaching the file and giving me the 
buffer size you used?
I will try to duplicate the problem.

Karl

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 14:51

Message:
Logged In: YES 
user_id=3066

Are you using Expat 1.95.3 or the CVS version of Expat?

If you're not using the CVS version, can you take a look at
that version and try to reproduce the problem?  You can get
information on getting the CVS version anonymously at:

http://www.libexpat.org/dev/cvs.html

Thanks!

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

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


From noreply@sourceforge.net  Fri Jul 12 09:21:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 08:21:10 2002
Subject: [ expat-Bugs-566238 ] 1.95.3: xmlwf startup time much longer
Message-ID: <E17T2Dy-00063h-00@usw-sf-web5.sourceforge.net>

Bugs item #566238, was opened at 2002-06-08 17:29
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=566238&group_id=10127

Category: Build control
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Rolf Ade (pointsman)
Assigned to: Greg Stein (gstein)
Summary: 1.95.3: xmlwf startup time much longer

Initial Comment:

At least at my linux box, I seems that the new way of
starting xmlwf - with a shell wrapper - heavily
increases the startup time of xmlwf.

For most people, this may be a really minor problem (it
isn't even a big one for me, though). But if you check
a lot of really small xml files with xmlwf in  one
commandline or a shell script, this is very notable. 

I've noticed it, while checking the (very small) test
files of the OASIS test suite. My shell scripts, that
does this, needed up to 10 times (!) longer, to finished.

To be sure, it's really the startup time, I checked
xmlwf against some bigger XML files (around 30 Mbyte)
and found only minor speed differences between 1.95.2
and 1.95.3. It seems, 1.95.3 is around 6 or 7 percent
slower than 1.95.2 (I've substracted the mesured longer
startup time of the 1.95.3 xmlwf from the running time,
befor calculation.)

rolf


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

>Comment By: Rolf Ade (pointsman)
Date: 2002-07-12 15:20

Message:
Logged In: YES 
user_id=13222

Greg,

well, you got me. Yes, I observed the slowdown of xmlwf,
while running it from the build copy. Yes, after
installation, there isn't a shell wrapper anymore, just the
xmlwf binary. I'm sorry about any irritation, I've triggered.

But - not to distract from my mistake, but because I'm
really a bit worried about - even beside this shell wrapper
thing (which is not a problem, I confirm)  expat is getting
slower and slower, from version to version. It's not
dramatic, but it sums up.

I've just done some tests, that confirmed that again. To
give some concrete numbers (on a linux 2.2.13, PII 333MHz,
384 MByte memory) from checking a around 100 MByte big XML
file with the according xmlwf tools (I ensured, that the
file is in the system cache)

With 1.92.3:

real    0m12.108s
user    0m11.360s
sys     0m0.660s

With 1.92.2:

real    0m11.152s
user    0m10.450s
sys     0m.670s

With James Clarks 1.2final:

real    0m9.471s
user    0m9.360s
sys     0m0.090s

This numbers are typical for all XML files, I've done this
comparson. To sum up the results, this is a solid 25 percent
slow down from 1.2 to 1.92.3.

Remarkable is the much greater sys part for the 1.92.x
versions. This may because of changed I/O code in the xmlwf
tool (haven't check this). But even  without this, there's a
notable slow down.

It's not dramatic, as said. Expat is still the fastest
compliant XML parser, I know. But to say it frankly, one of
the major points of using expat (if not the major point) is
simply its speed.

Some slow down may be unavoidable (for example due to the
reasent fix for better detection of invalid XML chars), but
I would love, if someone checks this - and the speed of
current versions in general - with a critical eye.

rolf


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

Comment By: Greg Stein (gstein)
Date: 2002-07-11 17:10

Message:
Logged In: YES 
user_id=6501

Rolf,

Was your slower time measured against xmlwf out of the build
tree, or an installed copy? As far as I can tell, we never
install the shell script wrapper. Within the build tree, it
will always be present (the first run will be slow while it
links, then it should be faster (but not as fast as without
the shell script, of course))

Anyways... we need to find out if your observation was for
the build or installed copy of xmlwf.

thx.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-29 15:28

Message:
Logged In: YES 
user_id=3066

This is painful, but not enough to hold up a bugfix release.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-26 04:58

Message:
Logged In: YES 
user_id=3066

Ugh!  This is heinous!  The crufty libtool wrapper should
never be installed, and even says so itself.

Greg, can you fix this soon?

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

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


From noreply@sourceforge.net  Fri Jul 12 09:40:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 08:40:03 2002
Subject: [ expat-Bugs-580258 ] Problem with GetBuffer/ParseBuffer
Message-ID: <E17T2Vz-0003fa-00@usw-sf-web1.sourceforge.net>

Bugs item #580258, was opened at 2002-07-11 15:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580258&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher M. Woods (cmwoods)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with GetBuffer/ParseBuffer

Initial Comment:
This is my first post so forgive me if I leave anything 
out...
     I've encountered a problem while using the 
XML_GetBuffer/XML_ParserBuffer methods of the Expat 
library.  [Using libexpatw.lib, on Win2K w/ MSVC++ 6.0 -
 sp5, wide chars (UNICODE), with a UTF-16 encoded 
XML file of roughly 33KB of data.]  When using these 
methods, I've experienced errors from the parser stating 
one of the following: not well-formed XML, illegal token, 
or unclosed token.  Each of the errors appear 
consistently for a given file and a given buffer size.
     I haven't narrowed down the problem yet - and will 
include more information once I get a chance to dig into 
the code further.  I can tell you that I get no errors on the 
file if I read it into my own buffer and use the XML_Parse 
method.  I can also tell you that I DO GET errors if I 
request a buffer large enough for the file, read the file 
into the buffer, and then call XML_ParseBuffer... so the 
problem appears to be [at least on the surface] with 
XML_ParseBuffer.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 11:39

Message:
Logged In: YES 
user_id=290026

Your sample project expats input redirection,
but that does not work on my system, it seems.
Using W2K, cmd.exe.

Karl

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 10:59

Message:
Logged In: YES 
user_id=576763

File was too large... I had to remove libexpatw_d.dll... you'll 
want to rebuild or change project settings to link to 
libexpatw.dll (for debug)

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 10:56

Message:
Logged In: YES 
user_id=576763

Hmm... I'll try again.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 10:09

Message:
Logged In: YES 
user_id=290026

I can't see your zip file.

Karl

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 09:41

Message:
Logged In: YES 
user_id=576763

   Hmm... Perhaps I'm missing something in my setup or the 
delphi code isn't quite the same?  I'm using wchar_t 
(UNICODE & _UNICODE defines) and maybe the issue is 
related to that?  I've included a sample project in the zip file 
that exhibits the behaviorism that I'm seeing.
   The libexpatw.lib is right from the win32bin distribution 
(1.95.3) and the libexpatw_d.lib is a debug build I made from 
the included source code.
   If you look in XMLExtractor.cpp, in the Process() function, 
starting at line 52, you'll see both methodologies are coded 
and one is commented out.  The GetBuffer/ParseBuffer 
method fails for me and the Parse method (the 2nd one) 
seems to work fine.  [Separate question: Why does 
XML_Parse take const char* and not XML_Char*?]
   I'd be perfectly happy if this turns out to be nothing more 
that a simple configuration problem on my part.  But I'm 
curious why it seems to work fine one way and not the other.

Thank you for your time,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 21:22

Message:
Logged In: YES 
user_id=290026

I cannot reproduce your problem with the current CVS
and also not with 1.95.3. I tested with the same buffer sizes 
you gave me.

I compiled the Dll with VC++6 (I believe I have SP5 also).
My test program is written in Delphi, but you can probably
still compare my parsing loop with yours:

const
  XML_READBUFSIZE = 65536;
...
IsFinal := False;
while not IsFinal do
  begin
  Buffer := XMLGetBuffer(Parser, XML_READBUFSIZE);
  if Buffer = nil then OutOfMemoryError;
  ReadCount := Stream.Read(Buffer^, XML_READBUFSIZE);
  IsFinal := ReadCount < XML_READBUFSIZE;
  if XMLParseBuffer(Parser, ReadCount, Integer(IsFinal)) = 0 
then
    begin
    ErrorCode := Ord(XMLGetErrorCode(Parser));
    ...
    Break;
    end;
  end;

Is that different?

Karl



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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-11 17:51

Message:
Logged In: YES 
user_id=576763

Frank,
   I was/am using the 1.95.3 version of the project.  I'll try the 
CVS version when I get a chance (very busy).

Karl,
   I've attached the sample file that I was using/having 
problems with.  I tried several buffer sizes including: 32768, 
65536, 1000000, and (if I remember correctly) 8192.

Thanks,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 16:01

Message:
Logged In: YES 
user_id=290026

Would you mind attaching the file and giving me the 
buffer size you used?
I will try to duplicate the problem.

Karl

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 15:51

Message:
Logged In: YES 
user_id=3066

Are you using Expat 1.95.3 or the CVS version of Expat?

If you're not using the CVS version, can you take a look at
that version and try to reproduce the problem?  You can get
information on getting the CVS version anonymously at:

http://www.libexpat.org/dev/cvs.html

Thanks!

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

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


From noreply@sourceforge.net  Fri Jul 12 10:03:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 09:03:05 2002
Subject: [ expat-Bugs-580258 ] Problem with GetBuffer/ParseBuffer
Message-ID: <E17T2sA-0007Rv-00@usw-sf-web5.sourceforge.net>

Bugs item #580258, was opened at 2002-07-11 14:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580258&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher M. Woods (cmwoods)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with GetBuffer/ParseBuffer

Initial Comment:
This is my first post so forgive me if I leave anything 
out...
     I've encountered a problem while using the 
XML_GetBuffer/XML_ParserBuffer methods of the Expat 
library.  [Using libexpatw.lib, on Win2K w/ MSVC++ 6.0 -
 sp5, wide chars (UNICODE), with a UTF-16 encoded 
XML file of roughly 33KB of data.]  When using these 
methods, I've experienced errors from the parser stating 
one of the following: not well-formed XML, illegal token, 
or unclosed token.  Each of the errors appear 
consistently for a given file and a given buffer size.
     I haven't narrowed down the problem yet - and will 
include more information once I get a chance to dig into 
the code further.  I can tell you that I get no errors on the 
file if I read it into my own buffer and use the XML_Parse 
method.  I can also tell you that I DO GET errors if I 
request a buffer large enough for the file, read the file 
into the buffer, and then call XML_ParseBuffer... so the 
problem appears to be [at least on the surface] with 
XML_ParseBuffer.

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

>Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 11:02

Message:
Logged In: YES 
user_id=576763

Karl,
   Don't know what to say... I'm using Win2K from the cmd 
line also...

Sample.cpp <D:\Temp\Sample\Sample.xml

-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 10:39

Message:
Logged In: YES 
user_id=290026

Your sample project expats input redirection,
but that does not work on my system, it seems.
Using W2K, cmd.exe.

Karl

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 09:59

Message:
Logged In: YES 
user_id=576763

File was too large... I had to remove libexpatw_d.dll... you'll 
want to rebuild or change project settings to link to 
libexpatw.dll (for debug)

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 09:56

Message:
Logged In: YES 
user_id=576763

Hmm... I'll try again.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 09:09

Message:
Logged In: YES 
user_id=290026

I can't see your zip file.

Karl

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 08:41

Message:
Logged In: YES 
user_id=576763

   Hmm... Perhaps I'm missing something in my setup or the 
delphi code isn't quite the same?  I'm using wchar_t 
(UNICODE & _UNICODE defines) and maybe the issue is 
related to that?  I've included a sample project in the zip file 
that exhibits the behaviorism that I'm seeing.
   The libexpatw.lib is right from the win32bin distribution 
(1.95.3) and the libexpatw_d.lib is a debug build I made from 
the included source code.
   If you look in XMLExtractor.cpp, in the Process() function, 
starting at line 52, you'll see both methodologies are coded 
and one is commented out.  The GetBuffer/ParseBuffer 
method fails for me and the Parse method (the 2nd one) 
seems to work fine.  [Separate question: Why does 
XML_Parse take const char* and not XML_Char*?]
   I'd be perfectly happy if this turns out to be nothing more 
that a simple configuration problem on my part.  But I'm 
curious why it seems to work fine one way and not the other.

Thank you for your time,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 20:22

Message:
Logged In: YES 
user_id=290026

I cannot reproduce your problem with the current CVS
and also not with 1.95.3. I tested with the same buffer sizes 
you gave me.

I compiled the Dll with VC++6 (I believe I have SP5 also).
My test program is written in Delphi, but you can probably
still compare my parsing loop with yours:

const
  XML_READBUFSIZE = 65536;
...
IsFinal := False;
while not IsFinal do
  begin
  Buffer := XMLGetBuffer(Parser, XML_READBUFSIZE);
  if Buffer = nil then OutOfMemoryError;
  ReadCount := Stream.Read(Buffer^, XML_READBUFSIZE);
  IsFinal := ReadCount < XML_READBUFSIZE;
  if XMLParseBuffer(Parser, ReadCount, Integer(IsFinal)) = 0 
then
    begin
    ErrorCode := Ord(XMLGetErrorCode(Parser));
    ...
    Break;
    end;
  end;

Is that different?

Karl



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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-11 16:51

Message:
Logged In: YES 
user_id=576763

Frank,
   I was/am using the 1.95.3 version of the project.  I'll try the 
CVS version when I get a chance (very busy).

Karl,
   I've attached the sample file that I was using/having 
problems with.  I tried several buffer sizes including: 32768, 
65536, 1000000, and (if I remember correctly) 8192.

Thanks,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 15:01

Message:
Logged In: YES 
user_id=290026

Would you mind attaching the file and giving me the 
buffer size you used?
I will try to duplicate the problem.

Karl

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 14:51

Message:
Logged In: YES 
user_id=3066

Are you using Expat 1.95.3 or the CVS version of Expat?

If you're not using the CVS version, can you take a look at
that version and try to reproduce the problem?  You can get
information on getting the CVS version anonymously at:

http://www.libexpat.org/dev/cvs.html

Thanks!

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

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


From noreply@sourceforge.net  Fri Jul 12 10:52:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 09:52:04 2002
Subject: [ expat-Bugs-580258 ] Problem with GetBuffer/ParseBuffer
Message-ID: <E17T3e3-0007WO-00@usw-sf-web4.sourceforge.net>

Bugs item #580258, was opened at 2002-07-11 15:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580258&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher M. Woods (cmwoods)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with GetBuffer/ParseBuffer

Initial Comment:
This is my first post so forgive me if I leave anything 
out...
     I've encountered a problem while using the 
XML_GetBuffer/XML_ParserBuffer methods of the Expat 
library.  [Using libexpatw.lib, on Win2K w/ MSVC++ 6.0 -
 sp5, wide chars (UNICODE), with a UTF-16 encoded 
XML file of roughly 33KB of data.]  When using these 
methods, I've experienced errors from the parser stating 
one of the following: not well-formed XML, illegal token, 
or unclosed token.  Each of the errors appear 
consistently for a given file and a given buffer size.
     I haven't narrowed down the problem yet - and will 
include more information once I get a chance to dig into 
the code further.  I can tell you that I get no errors on the 
file if I read it into my own buffer and use the XML_Parse 
method.  I can also tell you that I DO GET errors if I 
request a buffer large enough for the file, read the file 
into the buffer, and then call XML_ParseBuffer... so the 
problem appears to be [at least on the surface] with 
XML_ParseBuffer.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 12:51

Message:
Logged In: YES 
user_id=290026

I could get it to work, but it does not produce any 
output. Anyway, I had a look at your loop.

It should not work the way it is written.
Expat expects a buffer of bytes, but you are passing 
the buffer chunks as null terminated wide strings.
Expat can even handle it if the buffer boundaries are 
*within* a wide character.

The following code should work (or come close):

while (bRC && dwSize!=0)
{
  pBuffer = XML_GetBuffer(m_pParser, READ_SIZE);
    if (pBuffer)
  {
    dwSize = fread(pBuffer, 1, READ_SIZE, pInputFile);
    bRC = XML_ParseBuffer(m_pParser, dwSize, 
dwSize==0);
  } else {
    bRC = false;
  }
}

Please test. 
At this point I don't see a bug in Expat.

Karl

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 12:02

Message:
Logged In: YES 
user_id=576763

Karl,
   Don't know what to say... I'm using Win2K from the cmd 
line also...

Sample.cpp <D:\Temp\Sample\Sample.xml

-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 11:39

Message:
Logged In: YES 
user_id=290026

Your sample project expats input redirection,
but that does not work on my system, it seems.
Using W2K, cmd.exe.

Karl

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 10:59

Message:
Logged In: YES 
user_id=576763

File was too large... I had to remove libexpatw_d.dll... you'll 
want to rebuild or change project settings to link to 
libexpatw.dll (for debug)

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 10:56

Message:
Logged In: YES 
user_id=576763

Hmm... I'll try again.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 10:09

Message:
Logged In: YES 
user_id=290026

I can't see your zip file.

Karl

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 09:41

Message:
Logged In: YES 
user_id=576763

   Hmm... Perhaps I'm missing something in my setup or the 
delphi code isn't quite the same?  I'm using wchar_t 
(UNICODE & _UNICODE defines) and maybe the issue is 
related to that?  I've included a sample project in the zip file 
that exhibits the behaviorism that I'm seeing.
   The libexpatw.lib is right from the win32bin distribution 
(1.95.3) and the libexpatw_d.lib is a debug build I made from 
the included source code.
   If you look in XMLExtractor.cpp, in the Process() function, 
starting at line 52, you'll see both methodologies are coded 
and one is commented out.  The GetBuffer/ParseBuffer 
method fails for me and the Parse method (the 2nd one) 
seems to work fine.  [Separate question: Why does 
XML_Parse take const char* and not XML_Char*?]
   I'd be perfectly happy if this turns out to be nothing more 
that a simple configuration problem on my part.  But I'm 
curious why it seems to work fine one way and not the other.

Thank you for your time,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 21:22

Message:
Logged In: YES 
user_id=290026

I cannot reproduce your problem with the current CVS
and also not with 1.95.3. I tested with the same buffer sizes 
you gave me.

I compiled the Dll with VC++6 (I believe I have SP5 also).
My test program is written in Delphi, but you can probably
still compare my parsing loop with yours:

const
  XML_READBUFSIZE = 65536;
...
IsFinal := False;
while not IsFinal do
  begin
  Buffer := XMLGetBuffer(Parser, XML_READBUFSIZE);
  if Buffer = nil then OutOfMemoryError;
  ReadCount := Stream.Read(Buffer^, XML_READBUFSIZE);
  IsFinal := ReadCount < XML_READBUFSIZE;
  if XMLParseBuffer(Parser, ReadCount, Integer(IsFinal)) = 0 
then
    begin
    ErrorCode := Ord(XMLGetErrorCode(Parser));
    ...
    Break;
    end;
  end;

Is that different?

Karl



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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-11 17:51

Message:
Logged In: YES 
user_id=576763

Frank,
   I was/am using the 1.95.3 version of the project.  I'll try the 
CVS version when I get a chance (very busy).

Karl,
   I've attached the sample file that I was using/having 
problems with.  I tried several buffer sizes including: 32768, 
65536, 1000000, and (if I remember correctly) 8192.

Thanks,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 16:01

Message:
Logged In: YES 
user_id=290026

Would you mind attaching the file and giving me the 
buffer size you used?
I will try to duplicate the problem.

Karl

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 15:51

Message:
Logged In: YES 
user_id=3066

Are you using Expat 1.95.3 or the CVS version of Expat?

If you're not using the CVS version, can you take a look at
that version and try to reproduce the problem?  You can get
information on getting the CVS version anonymously at:

http://www.libexpat.org/dev/cvs.html

Thanks!

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

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


From noreply@sourceforge.net  Fri Jul 12 12:41:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 11:41:20 2002
Subject: [ expat-Patches-578161 ] Re: WFC: Entity Declared & Section 5.1
Message-ID: <E17T5Ki-00075j-00@usw-sf-web1.sourceforge.net>

Patches item #578161, was opened at 2002-07-06 13:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=578161&group_id=10127

Category: None
Group: None
>Status: Closed
Resolution: Accepted
Priority: 7
Submitted By: Karl Waclawek (kwaclaw)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Re: WFC: Entity Declared & Section 5.1

Initial Comment:
This patch addresses three issues:
1) Bug #569461:
(conformance with OASIS test-suite) - partial fix
2) Bug #570263 (attr default & external PEs)
3) tab->blank conversion for xmlparse.c.

See the attached files PatchDesc.txt
for a description, and PatchImpl.txt
for an overview of the implementation.

The patch consists of the attached files 
expat.h (based on CVS rev. 1.26) and
xmlparse.c (based on CVS rev. 1.47).
For diff purposes I have attached an "untabified"
version of xmlparse.c rev. 1.47, since a diff against
the CVS version would be meaningless.

Karl

P.S: I have not attached this to one of the bugs,
since it is too large a patch.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 14:40

Message:
Logged In: YES 
user_id=290026

Modified version of patch was checked in .

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-09 16:25

Message:
Logged In: YES 
user_id=3066

Per email with Karl, I've checked in a de-tabified version
of xmlparse.c, and he's going to follow with the checkin of
this patch, which I'm assigning back to him as accepted.

Karl, can you add a brief entry to Changes summarizing the
changes relating to PE and skipped entity handling?

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-08 22:50

Message:
Logged In: YES 
user_id=290026

OK, 
hopefully this time the script is really clean of any
DOS linebreaks. Attached as test2.sh.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-08 19:14

Message:
Logged In: YES 
user_id=290026

Fred, are you going to move 
XML_ERROR_ENTITY_DECLARED_IN_PE yourself,
or do you want me to do it?

Also, I attached an improved shellscript, provided
by Rolf Ade, since the one I wrote wouldn't run
on Unix witout some extra effort (Obviously, I never wrote
a shell script before :-) )

Karl



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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-08 18:20

Message:
Logged In: YES 
user_id=3066

API note:  XML_ERROR_ENTITY_DECLARED_IN_PE should be added
to the end of the XML_Error enum, otherwise code that uses
Expat needs to be re-compiled as well as re-linked for a new
version of the library.

Still reviewing all the changes; this is a pretty serious
patch!  Assigned to myself to finish reviewing.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-08 13:29

Message:
Logged In: YES 
user_id=290026

I ran a new shell script testing this patch against the
current version of the xml test suite available at:
http://www.w3.org/XML/Test/xmlts20020606.zip .

This new script adds the following functionality:
It tries to match the output files from the test suite
against those produced by xmlwf
(applying to valid test files only, of course).

It seems that basically the only differences found are,
that the canonical output in the test-suite includes
notation declarations, whereas xmlwf does not produce
them. Other than that, there is only one discrepancy
regarding ibm/valid/P02/ibm02v01.xml.

However, on the test-suite mailing list, it was reported
that the corresponding output file may be incorrect.
Check the archive at:
http://lists.w3.org/Archives/Public/public-xml-
testsuite/2002Jun/thread.html

Therefore it seems that the only mismatches the test
script found are due to the definition of "canonical"
output in xmlwf, which does not conform to the
w3 recommendation.

The script is attached as file test1.sh.
I was running it under Cygwin.
If you want to use it, you need to adjust the
definitions of $XMLWF and $OUTPUT for your
environment.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-07 20:31

Message:
Logged In: YES 
user_id=290026

I forgot to mention that the behaviour of the 
skippedEntityHandler callback was modified,
to be in line with the SAX2 specs, but also for
logical reasons:

It makes not much sense to report skipped parameter
entities in declarations and skipped general entities in
attribute values, because such events would be
"out of sync" with the sequence of other callbacks.

Btw, this is an issue that did also come up when
discussing the internalEntityRefHandler feature request, i.e.
when considering the option of *not* expanding such entities.

In this case we were thinking about a special (optional)
marker character (similar to the NS separator). That approach
would also be applicable to the case of skipped entities.

Karl

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

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


From noreply@sourceforge.net  Fri Jul 12 13:23:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 12:23:15 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17T5zt-00027q-00@usw-sf-web4.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 04:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ari Johnson (ari_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

>Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 14:22

Message:
Logged In: YES 
user_id=90811

Same thing occurs with the current CVS.  This even 
occurs when I actually send XML_Parse*() some text to 
process.  And to make things worse, XML_Parse() 
returns false since it's trying to parse text past the close 
tag of my root element, but the error code is set to 0.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:07

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 07:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

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


From noreply@sourceforge.net  Fri Jul 12 13:43:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 12:43:10 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17T6JR-00031v-00@usw-sf-web5.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 05:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ari Johnson (ari_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 15:42

Message:
Logged In: YES 
user_id=290026

In that case please post a small example that can
produce the behaviour you have reported.

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:22

Message:
Logged In: YES 
user_id=90811

Same thing occurs with the current CVS.  This even 
occurs when I actually send XML_Parse*() some text to 
process.  And to make things worse, XML_Parse() 
returns false since it's trying to parse text past the close 
tag of my root element, but the error code is set to 0.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 09:07

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

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


From noreply@sourceforge.net  Fri Jul 12 14:03:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 13:03:10 2002
Subject: [ expat-Bugs-566238 ] 1.95.3: xmlwf startup time much longer
Message-ID: <E17T6cV-0003R8-00@usw-sf-web5.sourceforge.net>

Bugs item #566238, was opened at 2002-06-08 13:29
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=566238&group_id=10127

Category: Build control
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Rolf Ade (pointsman)
Assigned to: Greg Stein (gstein)
Summary: 1.95.3: xmlwf startup time much longer

Initial Comment:

At least at my linux box, I seems that the new way of
starting xmlwf - with a shell wrapper - heavily
increases the startup time of xmlwf.

For most people, this may be a really minor problem (it
isn't even a big one for me, though). But if you check
a lot of really small xml files with xmlwf in  one
commandline or a shell script, this is very notable. 

I've noticed it, while checking the (very small) test
files of the OASIS test suite. My shell scripts, that
does this, needed up to 10 times (!) longer, to finished.

To be sure, it's really the startup time, I checked
xmlwf against some bigger XML files (around 30 Mbyte)
and found only minor speed differences between 1.95.2
and 1.95.3. It seems, 1.95.3 is around 6 or 7 percent
slower than 1.95.2 (I've substracted the mesured longer
startup time of the 1.95.3 xmlwf from the running time,
befor calculation.)

rolf


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-12 16:02

Message:
Logged In: YES 
user_id=3066

Rolf,

I think general slowdown is a separate issue from xmlwf
startup time, which appears to be either solved or a
non-issue at this point.

Would you be interested in doing some "regression
benchmarking" and possibly gathering profiling data to see
what portions of Expat are exhibiting the most change?

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

Comment By: Rolf Ade (pointsman)
Date: 2002-07-12 11:20

Message:
Logged In: YES 
user_id=13222

Greg,

well, you got me. Yes, I observed the slowdown of xmlwf,
while running it from the build copy. Yes, after
installation, there isn't a shell wrapper anymore, just the
xmlwf binary. I'm sorry about any irritation, I've triggered.

But - not to distract from my mistake, but because I'm
really a bit worried about - even beside this shell wrapper
thing (which is not a problem, I confirm)  expat is getting
slower and slower, from version to version. It's not
dramatic, but it sums up.

I've just done some tests, that confirmed that again. To
give some concrete numbers (on a linux 2.2.13, PII 333MHz,
384 MByte memory) from checking a around 100 MByte big XML
file with the according xmlwf tools (I ensured, that the
file is in the system cache)

With 1.92.3:

real    0m12.108s
user    0m11.360s
sys     0m0.660s

With 1.92.2:

real    0m11.152s
user    0m10.450s
sys     0m.670s

With James Clarks 1.2final:

real    0m9.471s
user    0m9.360s
sys     0m0.090s

This numbers are typical for all XML files, I've done this
comparson. To sum up the results, this is a solid 25 percent
slow down from 1.2 to 1.92.3.

Remarkable is the much greater sys part for the 1.92.x
versions. This may because of changed I/O code in the xmlwf
tool (haven't check this). But even  without this, there's a
notable slow down.

It's not dramatic, as said. Expat is still the fastest
compliant XML parser, I know. But to say it frankly, one of
the major points of using expat (if not the major point) is
simply its speed.

Some slow down may be unavoidable (for example due to the
reasent fix for better detection of invalid XML chars), but
I would love, if someone checks this - and the speed of
current versions in general - with a critical eye.

rolf


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

Comment By: Greg Stein (gstein)
Date: 2002-07-11 13:10

Message:
Logged In: YES 
user_id=6501

Rolf,

Was your slower time measured against xmlwf out of the build
tree, or an installed copy? As far as I can tell, we never
install the shell script wrapper. Within the build tree, it
will always be present (the first run will be slow while it
links, then it should be faster (but not as fast as without
the shell script, of course))

Anyways... we need to find out if your observation was for
the build or installed copy of xmlwf.

thx.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-29 11:28

Message:
Logged In: YES 
user_id=3066

This is painful, but not enough to hold up a bugfix release.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-26 00:58

Message:
Logged In: YES 
user_id=3066

Ugh!  This is heinous!  The crufty libtool wrapper should
never be installed, and even says so itself.

Greg, can you fix this soon?

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

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


From noreply@sourceforge.net  Fri Jul 12 14:11:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 13:11:09 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17T6kU-0000bG-00@usw-sf-web1.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 04:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ari Johnson (ari_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

>Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:10

Message:
Logged In: YES 
user_id=90811

I apologize for a mistake; the error it returns is 9 -> 
junk after document element.  I was calling 
GetErrorCode wrong.  Anyhow...

---
int c = 1024;
while(c == 1024) {
  char *buff = XML_GetBuffer(p, 1024);
  if(!buff)
    ...
  c = read(fd, buff, 1024);
  if(c < 0)
    ...
  if(!XML_ParseBuffer(p, c, 0))
    ...
}

...

void handle_end_element(...) {
  if([it was the root element]) {
    char *buff = XML_GetBuffer(p, 0);
    if(!XML_ParseBuffer(p, 0, 1))
      /* This is where the error occurs. */
  }
}


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 14:42

Message:
Logged In: YES 
user_id=290026

In that case please post a small example that can
produce the behaviour you have reported.

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 14:22

Message:
Logged In: YES 
user_id=90811

Same thing occurs with the current CVS.  This even 
occurs when I actually send XML_Parse*() some text to 
process.  And to make things worse, XML_Parse() 
returns false since it's trying to parse text past the close 
tag of my root element, but the error code is set to 0.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:07

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 07:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

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


From noreply@sourceforge.net  Fri Jul 12 14:30:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 13:30:03 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17T72K-00043u-00@usw-sf-web5.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 04:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ari Johnson (ari_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

>Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:29

Message:
Logged In: YES 
user_id=90811

Just an update...the same thing happens when I don't 
set isFinal in the error-producing call, or of course if I 
feed it more text (since this is just after the </root> tag 
has been read).

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:10

Message:
Logged In: YES 
user_id=90811

I apologize for a mistake; the error it returns is 9 -> 
junk after document element.  I was calling 
GetErrorCode wrong.  Anyhow...

---
int c = 1024;
while(c == 1024) {
  char *buff = XML_GetBuffer(p, 1024);
  if(!buff)
    ...
  c = read(fd, buff, 1024);
  if(c < 0)
    ...
  if(!XML_ParseBuffer(p, c, 0))
    ...
}

...

void handle_end_element(...) {
  if([it was the root element]) {
    char *buff = XML_GetBuffer(p, 0);
    if(!XML_ParseBuffer(p, 0, 1))
      /* This is where the error occurs. */
  }
}


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 14:42

Message:
Logged In: YES 
user_id=290026

In that case please post a small example that can
produce the behaviour you have reported.

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 14:22

Message:
Logged In: YES 
user_id=90811

Same thing occurs with the current CVS.  This even 
occurs when I actually send XML_Parse*() some text to 
process.  And to make things worse, XML_Parse() 
returns false since it's trying to parse text past the close 
tag of my root element, but the error code is set to 0.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:07

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 07:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

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


From noreply@sourceforge.net  Fri Jul 12 14:35:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 13:35:22 2002
Subject: [ expat-Bugs-580258 ] Problem with GetBuffer/ParseBuffer
Message-ID: <E17T77B-0003JK-00@usw-sf-web4.sourceforge.net>

Bugs item #580258, was opened at 2002-07-11 14:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580258&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher M. Woods (cmwoods)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with GetBuffer/ParseBuffer

Initial Comment:
This is my first post so forgive me if I leave anything 
out...
     I've encountered a problem while using the 
XML_GetBuffer/XML_ParserBuffer methods of the Expat 
library.  [Using libexpatw.lib, on Win2K w/ MSVC++ 6.0 -
 sp5, wide chars (UNICODE), with a UTF-16 encoded 
XML file of roughly 33KB of data.]  When using these 
methods, I've experienced errors from the parser stating 
one of the following: not well-formed XML, illegal token, 
or unclosed token.  Each of the errors appear 
consistently for a given file and a given buffer size.
     I haven't narrowed down the problem yet - and will 
include more information once I get a chance to dig into 
the code further.  I can tell you that I get no errors on the 
file if I read it into my own buffer and use the XML_Parse 
method.  I can also tell you that I DO GET errors if I 
request a buffer large enough for the file, read the file 
into the buffer, and then call XML_ParseBuffer... so the 
problem appears to be [at least on the surface] with 
XML_ParseBuffer.

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

>Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 15:34

Message:
Logged In: YES 
user_id=576763

Karl,
     Your suggestion worked - thank you.  You can pull this 
from the bug list then.

-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 11:51

Message:
Logged In: YES 
user_id=290026

I could get it to work, but it does not produce any 
output. Anyway, I had a look at your loop.

It should not work the way it is written.
Expat expects a buffer of bytes, but you are passing 
the buffer chunks as null terminated wide strings.
Expat can even handle it if the buffer boundaries are 
*within* a wide character.

The following code should work (or come close):

while (bRC && dwSize!=0)
{
  pBuffer = XML_GetBuffer(m_pParser, READ_SIZE);
    if (pBuffer)
  {
    dwSize = fread(pBuffer, 1, READ_SIZE, pInputFile);
    bRC = XML_ParseBuffer(m_pParser, dwSize, 
dwSize==0);
  } else {
    bRC = false;
  }
}

Please test. 
At this point I don't see a bug in Expat.

Karl

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 11:02

Message:
Logged In: YES 
user_id=576763

Karl,
   Don't know what to say... I'm using Win2K from the cmd 
line also...

Sample.cpp <D:\Temp\Sample\Sample.xml

-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 10:39

Message:
Logged In: YES 
user_id=290026

Your sample project expats input redirection,
but that does not work on my system, it seems.
Using W2K, cmd.exe.

Karl

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 09:59

Message:
Logged In: YES 
user_id=576763

File was too large... I had to remove libexpatw_d.dll... you'll 
want to rebuild or change project settings to link to 
libexpatw.dll (for debug)

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 09:56

Message:
Logged In: YES 
user_id=576763

Hmm... I'll try again.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 09:09

Message:
Logged In: YES 
user_id=290026

I can't see your zip file.

Karl

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 08:41

Message:
Logged In: YES 
user_id=576763

   Hmm... Perhaps I'm missing something in my setup or the 
delphi code isn't quite the same?  I'm using wchar_t 
(UNICODE & _UNICODE defines) and maybe the issue is 
related to that?  I've included a sample project in the zip file 
that exhibits the behaviorism that I'm seeing.
   The libexpatw.lib is right from the win32bin distribution 
(1.95.3) and the libexpatw_d.lib is a debug build I made from 
the included source code.
   If you look in XMLExtractor.cpp, in the Process() function, 
starting at line 52, you'll see both methodologies are coded 
and one is commented out.  The GetBuffer/ParseBuffer 
method fails for me and the Parse method (the 2nd one) 
seems to work fine.  [Separate question: Why does 
XML_Parse take const char* and not XML_Char*?]
   I'd be perfectly happy if this turns out to be nothing more 
that a simple configuration problem on my part.  But I'm 
curious why it seems to work fine one way and not the other.

Thank you for your time,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 20:22

Message:
Logged In: YES 
user_id=290026

I cannot reproduce your problem with the current CVS
and also not with 1.95.3. I tested with the same buffer sizes 
you gave me.

I compiled the Dll with VC++6 (I believe I have SP5 also).
My test program is written in Delphi, but you can probably
still compare my parsing loop with yours:

const
  XML_READBUFSIZE = 65536;
...
IsFinal := False;
while not IsFinal do
  begin
  Buffer := XMLGetBuffer(Parser, XML_READBUFSIZE);
  if Buffer = nil then OutOfMemoryError;
  ReadCount := Stream.Read(Buffer^, XML_READBUFSIZE);
  IsFinal := ReadCount < XML_READBUFSIZE;
  if XMLParseBuffer(Parser, ReadCount, Integer(IsFinal)) = 0 
then
    begin
    ErrorCode := Ord(XMLGetErrorCode(Parser));
    ...
    Break;
    end;
  end;

Is that different?

Karl



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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-11 16:51

Message:
Logged In: YES 
user_id=576763

Frank,
   I was/am using the 1.95.3 version of the project.  I'll try the 
CVS version when I get a chance (very busy).

Karl,
   I've attached the sample file that I was using/having 
problems with.  I tried several buffer sizes including: 32768, 
65536, 1000000, and (if I remember correctly) 8192.

Thanks,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 15:01

Message:
Logged In: YES 
user_id=290026

Would you mind attaching the file and giving me the 
buffer size you used?
I will try to duplicate the problem.

Karl

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 14:51

Message:
Logged In: YES 
user_id=3066

Are you using Expat 1.95.3 or the CVS version of Expat?

If you're not using the CVS version, can you take a look at
that version and try to reproduce the problem?  You can get
information on getting the CVS version anonymously at:

http://www.libexpat.org/dev/cvs.html

Thanks!

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

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


From noreply@sourceforge.net  Fri Jul 12 14:38:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 13:38:09 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17T7AR-00046n-00@usw-sf-web2.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 05:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ari Johnson (ari_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 16:37

Message:
Logged In: YES 
user_id=290026

Try removing the call for getting a zero sized buffer:
  char *buff = XML_GetBuffer(p, 0);
or change the size parameter back to 1024.
Does that have any effect?


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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:29

Message:
Logged In: YES 
user_id=90811

Just an update...the same thing happens when I don't 
set isFinal in the error-producing call, or of course if I 
feed it more text (since this is just after the </root> tag 
has been read).

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:10

Message:
Logged In: YES 
user_id=90811

I apologize for a mistake; the error it returns is 9 -> 
junk after document element.  I was calling 
GetErrorCode wrong.  Anyhow...

---
int c = 1024;
while(c == 1024) {
  char *buff = XML_GetBuffer(p, 1024);
  if(!buff)
    ...
  c = read(fd, buff, 1024);
  if(c < 0)
    ...
  if(!XML_ParseBuffer(p, c, 0))
    ...
}

...

void handle_end_element(...) {
  if([it was the root element]) {
    char *buff = XML_GetBuffer(p, 0);
    if(!XML_ParseBuffer(p, 0, 1))
      /* This is where the error occurs. */
  }
}


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 15:42

Message:
Logged In: YES 
user_id=290026

In that case please post a small example that can
produce the behaviour you have reported.

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:22

Message:
Logged In: YES 
user_id=90811

Same thing occurs with the current CVS.  This even 
occurs when I actually send XML_Parse*() some text to 
process.  And to make things worse, XML_Parse() 
returns false since it's trying to parse text past the close 
tag of my root element, but the error code is set to 0.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 09:07

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

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


From noreply@sourceforge.net  Fri Jul 12 14:40:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 13:40:02 2002
Subject: [ expat-Bugs-580258 ] Problem with GetBuffer/ParseBuffer
Message-ID: <E17T7Bv-0003Oe-00@usw-sf-web4.sourceforge.net>

Bugs item #580258, was opened at 2002-07-11 15:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580258&group_id=10127

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Christopher M. Woods (cmwoods)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with GetBuffer/ParseBuffer

Initial Comment:
This is my first post so forgive me if I leave anything 
out...
     I've encountered a problem while using the 
XML_GetBuffer/XML_ParserBuffer methods of the Expat 
library.  [Using libexpatw.lib, on Win2K w/ MSVC++ 6.0 -
 sp5, wide chars (UNICODE), with a UTF-16 encoded 
XML file of roughly 33KB of data.]  When using these 
methods, I've experienced errors from the parser stating 
one of the following: not well-formed XML, illegal token, 
or unclosed token.  Each of the errors appear 
consistently for a given file and a given buffer size.
     I haven't narrowed down the problem yet - and will 
include more information once I get a chance to dig into 
the code further.  I can tell you that I get no errors on the 
file if I read it into my own buffer and use the XML_Parse 
method.  I can also tell you that I DO GET errors if I 
request a buffer large enough for the file, read the file 
into the buffer, and then call XML_ParseBuffer... so the 
problem appears to be [at least on the surface] with 
XML_ParseBuffer.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 16:39

Message:
Logged In: YES 
user_id=290026

Great!
Bug report closed.

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 16:34

Message:
Logged In: YES 
user_id=576763

Karl,
     Your suggestion worked - thank you.  You can pull this 
from the bug list then.

-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 12:51

Message:
Logged In: YES 
user_id=290026

I could get it to work, but it does not produce any 
output. Anyway, I had a look at your loop.

It should not work the way it is written.
Expat expects a buffer of bytes, but you are passing 
the buffer chunks as null terminated wide strings.
Expat can even handle it if the buffer boundaries are 
*within* a wide character.

The following code should work (or come close):

while (bRC && dwSize!=0)
{
  pBuffer = XML_GetBuffer(m_pParser, READ_SIZE);
    if (pBuffer)
  {
    dwSize = fread(pBuffer, 1, READ_SIZE, pInputFile);
    bRC = XML_ParseBuffer(m_pParser, dwSize, 
dwSize==0);
  } else {
    bRC = false;
  }
}

Please test. 
At this point I don't see a bug in Expat.

Karl

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 12:02

Message:
Logged In: YES 
user_id=576763

Karl,
   Don't know what to say... I'm using Win2K from the cmd 
line also...

Sample.cpp <D:\Temp\Sample\Sample.xml

-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 11:39

Message:
Logged In: YES 
user_id=290026

Your sample project expats input redirection,
but that does not work on my system, it seems.
Using W2K, cmd.exe.

Karl

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 10:59

Message:
Logged In: YES 
user_id=576763

File was too large... I had to remove libexpatw_d.dll... you'll 
want to rebuild or change project settings to link to 
libexpatw.dll (for debug)

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 10:56

Message:
Logged In: YES 
user_id=576763

Hmm... I'll try again.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 10:09

Message:
Logged In: YES 
user_id=290026

I can't see your zip file.

Karl

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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-12 09:41

Message:
Logged In: YES 
user_id=576763

   Hmm... Perhaps I'm missing something in my setup or the 
delphi code isn't quite the same?  I'm using wchar_t 
(UNICODE & _UNICODE defines) and maybe the issue is 
related to that?  I've included a sample project in the zip file 
that exhibits the behaviorism that I'm seeing.
   The libexpatw.lib is right from the win32bin distribution 
(1.95.3) and the libexpatw_d.lib is a debug build I made from 
the included source code.
   If you look in XMLExtractor.cpp, in the Process() function, 
starting at line 52, you'll see both methodologies are coded 
and one is commented out.  The GetBuffer/ParseBuffer 
method fails for me and the Parse method (the 2nd one) 
seems to work fine.  [Separate question: Why does 
XML_Parse take const char* and not XML_Char*?]
   I'd be perfectly happy if this turns out to be nothing more 
that a simple configuration problem on my part.  But I'm 
curious why it seems to work fine one way and not the other.

Thank you for your time,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 21:22

Message:
Logged In: YES 
user_id=290026

I cannot reproduce your problem with the current CVS
and also not with 1.95.3. I tested with the same buffer sizes 
you gave me.

I compiled the Dll with VC++6 (I believe I have SP5 also).
My test program is written in Delphi, but you can probably
still compare my parsing loop with yours:

const
  XML_READBUFSIZE = 65536;
...
IsFinal := False;
while not IsFinal do
  begin
  Buffer := XMLGetBuffer(Parser, XML_READBUFSIZE);
  if Buffer = nil then OutOfMemoryError;
  ReadCount := Stream.Read(Buffer^, XML_READBUFSIZE);
  IsFinal := ReadCount < XML_READBUFSIZE;
  if XMLParseBuffer(Parser, ReadCount, Integer(IsFinal)) = 0 
then
    begin
    ErrorCode := Ord(XMLGetErrorCode(Parser));
    ...
    Break;
    end;
  end;

Is that different?

Karl



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

Comment By: Christopher M. Woods (cmwoods)
Date: 2002-07-11 17:51

Message:
Logged In: YES 
user_id=576763

Frank,
   I was/am using the 1.95.3 version of the project.  I'll try the 
CVS version when I get a chance (very busy).

Karl,
   I've attached the sample file that I was using/having 
problems with.  I tried several buffer sizes including: 32768, 
65536, 1000000, and (if I remember correctly) 8192.

Thanks,
-Chris

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-11 16:01

Message:
Logged In: YES 
user_id=290026

Would you mind attaching the file and giving me the 
buffer size you used?
I will try to duplicate the problem.

Karl

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-11 15:51

Message:
Logged In: YES 
user_id=3066

Are you using Expat 1.95.3 or the CVS version of Expat?

If you're not using the CVS version, can you take a look at
that version and try to reproduce the problem?  You can get
information on getting the CVS version anonymously at:

http://www.libexpat.org/dev/cvs.html

Thanks!

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

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


From noreply@sourceforge.net  Fri Jul 12 15:05:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 14:05:08 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17T7aP-0004aO-00@usw-sf-web2.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 04:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ari Johnson (ari_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

>Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:04

Message:
Logged In: YES 
user_id=90811

It doesn't matter what size buffer I request, the 
XML_ParseBuffer() call ends up re-parsing the previous 
buffer when I give it a zero size argument.  Also, even if 
I feed it a fictitious XML comment, it still gives me the 
error 9 - junk after document element.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 15:37

Message:
Logged In: YES 
user_id=290026

Try removing the call for getting a zero sized buffer:
  char *buff = XML_GetBuffer(p, 0);
or change the size parameter back to 1024.
Does that have any effect?


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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:29

Message:
Logged In: YES 
user_id=90811

Just an update...the same thing happens when I don't 
set isFinal in the error-producing call, or of course if I 
feed it more text (since this is just after the </root> tag 
has been read).

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:10

Message:
Logged In: YES 
user_id=90811

I apologize for a mistake; the error it returns is 9 -> 
junk after document element.  I was calling 
GetErrorCode wrong.  Anyhow...

---
int c = 1024;
while(c == 1024) {
  char *buff = XML_GetBuffer(p, 1024);
  if(!buff)
    ...
  c = read(fd, buff, 1024);
  if(c < 0)
    ...
  if(!XML_ParseBuffer(p, c, 0))
    ...
}

...

void handle_end_element(...) {
  if([it was the root element]) {
    char *buff = XML_GetBuffer(p, 0);
    if(!XML_ParseBuffer(p, 0, 1))
      /* This is where the error occurs. */
  }
}


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 14:42

Message:
Logged In: YES 
user_id=290026

In that case please post a small example that can
produce the behaviour you have reported.

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 14:22

Message:
Logged In: YES 
user_id=90811

Same thing occurs with the current CVS.  This even 
occurs when I actually send XML_Parse*() some text to 
process.  And to make things worse, XML_Parse() 
returns false since it's trying to parse text past the close 
tag of my root element, but the error code is set to 0.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:07

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 07:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

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


From noreply@sourceforge.net  Fri Jul 12 15:14:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 14:14:02 2002
Subject: [ expat-Bugs-580793 ] BCB5 Build does not work
Message-ID: <E17T7iq-0003yY-00@usw-sf-web4.sourceforge.net>

Bugs item #580793, was opened at 2002-07-12 17:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580793&group_id=10127

Category: Build control
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Karl Waclawek (kwaclaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: BCB5 Build does not work

Initial Comment:
I tried to build for the free command line version 
of Borland C++ Builder, but no luck.
Seems some of the directory references in
the make files don't match the CVS directory 
structure.

I have fixed this and also changed the main 
makefile where it uses DOS commands
 - deltree does not exist on W2K.

I also added a short ReadMe file.

Attached is a zip of the whole bcb5 directory.

Karl

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

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


From noreply@sourceforge.net  Fri Jul 12 15:16:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 14:16:07 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17T7l0-0001oo-00@usw-sf-web1.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 05:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ari Johnson (ari_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 17:15

Message:
Logged In: YES 
user_id=290026

Since I cannot duplicate this, do you have access
to another platform/OS and can you try it there?
Maybe it is related to the fact that you are compiling
and running this on your version of FreeBSD.



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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:04

Message:
Logged In: YES 
user_id=90811

It doesn't matter what size buffer I request, the 
XML_ParseBuffer() call ends up re-parsing the previous 
buffer when I give it a zero size argument.  Also, even if 
I feed it a fictitious XML comment, it still gives me the 
error 9 - junk after document element.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 16:37

Message:
Logged In: YES 
user_id=290026

Try removing the call for getting a zero sized buffer:
  char *buff = XML_GetBuffer(p, 0);
or change the size parameter back to 1024.
Does that have any effect?


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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:29

Message:
Logged In: YES 
user_id=90811

Just an update...the same thing happens when I don't 
set isFinal in the error-producing call, or of course if I 
feed it more text (since this is just after the </root> tag 
has been read).

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:10

Message:
Logged In: YES 
user_id=90811

I apologize for a mistake; the error it returns is 9 -> 
junk after document element.  I was calling 
GetErrorCode wrong.  Anyhow...

---
int c = 1024;
while(c == 1024) {
  char *buff = XML_GetBuffer(p, 1024);
  if(!buff)
    ...
  c = read(fd, buff, 1024);
  if(c < 0)
    ...
  if(!XML_ParseBuffer(p, c, 0))
    ...
}

...

void handle_end_element(...) {
  if([it was the root element]) {
    char *buff = XML_GetBuffer(p, 0);
    if(!XML_ParseBuffer(p, 0, 1))
      /* This is where the error occurs. */
  }
}


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 15:42

Message:
Logged In: YES 
user_id=290026

In that case please post a small example that can
produce the behaviour you have reported.

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:22

Message:
Logged In: YES 
user_id=90811

Same thing occurs with the current CVS.  This even 
occurs when I actually send XML_Parse*() some text to 
process.  And to make things worse, XML_Parse() 
returns false since it's trying to parse text past the close 
tag of my root element, but the error code is set to 0.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 09:07

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

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


From noreply@sourceforge.net  Fri Jul 12 16:09:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 15:09:19 2002
Subject: [ expat-Bugs-566238 ] 1.95.3: xmlwf startup time much longer
Message-ID: <E17T8aX-0003TN-00@usw-sf-web3.sourceforge.net>

Bugs item #566238, was opened at 2002-06-08 10:29
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=566238&group_id=10127

Category: Build control
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 6
Submitted By: Rolf Ade (pointsman)
Assigned to: Greg Stein (gstein)
Summary: 1.95.3: xmlwf startup time much longer

Initial Comment:

At least at my linux box, I seems that the new way of
starting xmlwf - with a shell wrapper - heavily
increases the startup time of xmlwf.

For most people, this may be a really minor problem (it
isn't even a big one for me, though). But if you check
a lot of really small xml files with xmlwf in  one
commandline or a shell script, this is very notable. 

I've noticed it, while checking the (very small) test
files of the OASIS test suite. My shell scripts, that
does this, needed up to 10 times (!) longer, to finished.

To be sure, it's really the startup time, I checked
xmlwf against some bigger XML files (around 30 Mbyte)
and found only minor speed differences between 1.95.2
and 1.95.3. It seems, 1.95.3 is around 6 or 7 percent
slower than 1.95.2 (I've substracted the mesured longer
startup time of the 1.95.3 xmlwf from the running time,
befor calculation.)

rolf


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

>Comment By: Greg Stein (gstein)
Date: 2002-07-12 15:08

Message:
Logged In: YES 
user_id=6501

No worries... I don't feel you wasted my time. And the
testing, commentary, suggestions, etc that you've provided
are definitely appreciated!

Closing this issue.


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

Comment By: Rolf Ade (pointsman)
Date: 2002-07-12 14:45

Message:
Logged In: YES 
user_id=13222


Fred,

you're of course right, the general slowdown is a seperate
issue. I'll open a seperate bug report for this.

To confirm this cleary, the xmlwf startup time is definitely
a non-issue (there was nothing to solve, right from the start.)

I just not noticed that. This time, my habit, to test
software, befor I install it system wide has bitten me :-(.

Again, sorry for any wasted time.

rolf


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-12 13:02

Message:
Logged In: YES 
user_id=3066

Rolf,

I think general slowdown is a separate issue from xmlwf
startup time, which appears to be either solved or a
non-issue at this point.

Would you be interested in doing some "regression
benchmarking" and possibly gathering profiling data to see
what portions of Expat are exhibiting the most change?

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

Comment By: Rolf Ade (pointsman)
Date: 2002-07-12 08:20

Message:
Logged In: YES 
user_id=13222

Greg,

well, you got me. Yes, I observed the slowdown of xmlwf,
while running it from the build copy. Yes, after
installation, there isn't a shell wrapper anymore, just the
xmlwf binary. I'm sorry about any irritation, I've triggered.

But - not to distract from my mistake, but because I'm
really a bit worried about - even beside this shell wrapper
thing (which is not a problem, I confirm)  expat is getting
slower and slower, from version to version. It's not
dramatic, but it sums up.

I've just done some tests, that confirmed that again. To
give some concrete numbers (on a linux 2.2.13, PII 333MHz,
384 MByte memory) from checking a around 100 MByte big XML
file with the according xmlwf tools (I ensured, that the
file is in the system cache)

With 1.92.3:

real    0m12.108s
user    0m11.360s
sys     0m0.660s

With 1.92.2:

real    0m11.152s
user    0m10.450s
sys     0m.670s

With James Clarks 1.2final:

real    0m9.471s
user    0m9.360s
sys     0m0.090s

This numbers are typical for all XML files, I've done this
comparson. To sum up the results, this is a solid 25 percent
slow down from 1.2 to 1.92.3.

Remarkable is the much greater sys part for the 1.92.x
versions. This may because of changed I/O code in the xmlwf
tool (haven't check this). But even  without this, there's a
notable slow down.

It's not dramatic, as said. Expat is still the fastest
compliant XML parser, I know. But to say it frankly, one of
the major points of using expat (if not the major point) is
simply its speed.

Some slow down may be unavoidable (for example due to the
reasent fix for better detection of invalid XML chars), but
I would love, if someone checks this - and the speed of
current versions in general - with a critical eye.

rolf


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

Comment By: Greg Stein (gstein)
Date: 2002-07-11 10:10

Message:
Logged In: YES 
user_id=6501

Rolf,

Was your slower time measured against xmlwf out of the build
tree, or an installed copy? As far as I can tell, we never
install the shell script wrapper. Within the build tree, it
will always be present (the first run will be slow while it
links, then it should be faster (but not as fast as without
the shell script, of course))

Anyways... we need to find out if your observation was for
the build or installed copy of xmlwf.

thx.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-29 08:28

Message:
Logged In: YES 
user_id=3066

This is painful, but not enough to hold up a bugfix release.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-25 21:58

Message:
Logged In: YES 
user_id=3066

Ugh!  This is heinous!  The crufty libtool wrapper should
never be installed, and even says so itself.

Greg, can you fix this soon?

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

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


From noreply@sourceforge.net  Fri Jul 12 16:28:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 15:28:02 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17T80o-0002lY-00@usw-sf-web3.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 05:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ari Johnson (ari_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 17:31

Message:
Logged In: YES 
user_id=290026

Another thought:

If your file size is a multiple of 1024, your code will
call XML_ParseBuffer twice with a buffer size of zero.

This is probably not what is was intended for.
If your file size happens to be like that, maybe you
could try another approach?

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:28

Message:
Logged In: YES 
user_id=90811

I've narrowed the problem down considerably...

I had XML_ParseBuffer() print out 'start' to stderr after it 
sets start in the first bit of the function.  What I found is 
that the contents are correct, for example if I set my 
buffer to equal "<!-- this is a comment -->", then that 
string gets appended to the end of the buffer where it 
should be.  However, start still points to the beginning 
of the previous segment of the buffered text.  This is 
only apparently happening on the call to 
XML_ParseBuffer() after the call that doesn't use the full 
size of the buffer.

Attached, please find a .tar.gz (warning, no directory 
structure, but only 4 files so it shouldn't cause a mess 
for you) with the actual code I'm using.  You'll have to 
compile test.c and xmlstream.c manually and then link 
them to form an executable.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 17:15

Message:
Logged In: YES 
user_id=290026

Since I cannot duplicate this, do you have access
to another platform/OS and can you try it there?
Maybe it is related to the fact that you are compiling
and running this on your version of FreeBSD.



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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:04

Message:
Logged In: YES 
user_id=90811

It doesn't matter what size buffer I request, the 
XML_ParseBuffer() call ends up re-parsing the previous 
buffer when I give it a zero size argument.  Also, even if 
I feed it a fictitious XML comment, it still gives me the 
error 9 - junk after document element.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 16:37

Message:
Logged In: YES 
user_id=290026

Try removing the call for getting a zero sized buffer:
  char *buff = XML_GetBuffer(p, 0);
or change the size parameter back to 1024.
Does that have any effect?


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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:29

Message:
Logged In: YES 
user_id=90811

Just an update...the same thing happens when I don't 
set isFinal in the error-producing call, or of course if I 
feed it more text (since this is just after the </root> tag 
has been read).

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:10

Message:
Logged In: YES 
user_id=90811

I apologize for a mistake; the error it returns is 9 -> 
junk after document element.  I was calling 
GetErrorCode wrong.  Anyhow...

---
int c = 1024;
while(c == 1024) {
  char *buff = XML_GetBuffer(p, 1024);
  if(!buff)
    ...
  c = read(fd, buff, 1024);
  if(c < 0)
    ...
  if(!XML_ParseBuffer(p, c, 0))
    ...
}

...

void handle_end_element(...) {
  if([it was the root element]) {
    char *buff = XML_GetBuffer(p, 0);
    if(!XML_ParseBuffer(p, 0, 1))
      /* This is where the error occurs. */
  }
}


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 15:42

Message:
Logged In: YES 
user_id=290026

In that case please post a small example that can
produce the behaviour you have reported.

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:22

Message:
Logged In: YES 
user_id=90811

Same thing occurs with the current CVS.  This even 
occurs when I actually send XML_Parse*() some text to 
process.  And to make things worse, XML_Parse() 
returns false since it's trying to parse text past the close 
tag of my root element, but the error code is set to 0.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 09:07

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

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


From noreply@sourceforge.net  Fri Jul 12 16:48:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 15:48:15 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17T83Q-0002qg-00@usw-sf-web3.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 04:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ari Johnson (ari_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

>Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:34

Message:
Logged In: YES 
user_id=90811

Forgot about my platform-specific code...in test.c, 
change 'stdin->_file' to '0' and 'stdout->_file' to '1'.  
And to run it, ./test < jabber.xml > output.xml


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 16:31

Message:
Logged In: YES 
user_id=290026

Another thought:

If your file size is a multiple of 1024, your code will
call XML_ParseBuffer twice with a buffer size of zero.

This is probably not what is was intended for.
If your file size happens to be like that, maybe you
could try another approach?

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:28

Message:
Logged In: YES 
user_id=90811

I've narrowed the problem down considerably...

I had XML_ParseBuffer() print out 'start' to stderr after it 
sets start in the first bit of the function.  What I found is 
that the contents are correct, for example if I set my 
buffer to equal "<!-- this is a comment -->", then that 
string gets appended to the end of the buffer where it 
should be.  However, start still points to the beginning 
of the previous segment of the buffered text.  This is 
only apparently happening on the call to 
XML_ParseBuffer() after the call that doesn't use the full 
size of the buffer.

Attached, please find a .tar.gz (warning, no directory 
structure, but only 4 files so it shouldn't cause a mess 
for you) with the actual code I'm using.  You'll have to 
compile test.c and xmlstream.c manually and then link 
them to form an executable.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 16:15

Message:
Logged In: YES 
user_id=290026

Since I cannot duplicate this, do you have access
to another platform/OS and can you try it there?
Maybe it is related to the fact that you are compiling
and running this on your version of FreeBSD.



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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:04

Message:
Logged In: YES 
user_id=90811

It doesn't matter what size buffer I request, the 
XML_ParseBuffer() call ends up re-parsing the previous 
buffer when I give it a zero size argument.  Also, even if 
I feed it a fictitious XML comment, it still gives me the 
error 9 - junk after document element.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 15:37

Message:
Logged In: YES 
user_id=290026

Try removing the call for getting a zero sized buffer:
  char *buff = XML_GetBuffer(p, 0);
or change the size parameter back to 1024.
Does that have any effect?


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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:29

Message:
Logged In: YES 
user_id=90811

Just an update...the same thing happens when I don't 
set isFinal in the error-producing call, or of course if I 
feed it more text (since this is just after the </root> tag 
has been read).

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:10

Message:
Logged In: YES 
user_id=90811

I apologize for a mistake; the error it returns is 9 -> 
junk after document element.  I was calling 
GetErrorCode wrong.  Anyhow...

---
int c = 1024;
while(c == 1024) {
  char *buff = XML_GetBuffer(p, 1024);
  if(!buff)
    ...
  c = read(fd, buff, 1024);
  if(c < 0)
    ...
  if(!XML_ParseBuffer(p, c, 0))
    ...
}

...

void handle_end_element(...) {
  if([it was the root element]) {
    char *buff = XML_GetBuffer(p, 0);
    if(!XML_ParseBuffer(p, 0, 1))
      /* This is where the error occurs. */
  }
}


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 14:42

Message:
Logged In: YES 
user_id=290026

In that case please post a small example that can
produce the behaviour you have reported.

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 14:22

Message:
Logged In: YES 
user_id=90811

Same thing occurs with the current CVS.  This even 
occurs when I actually send XML_Parse*() some text to 
process.  And to make things worse, XML_Parse() 
returns false since it's trying to parse text past the close 
tag of my root element, but the error code is set to 0.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:07

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 07:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

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


From noreply@sourceforge.net  Fri Jul 12 16:56:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 15:56:15 2002
Subject: [ expat-Bugs-566238 ] 1.95.3: xmlwf startup time much longer
Message-ID: <E17T8E3-0005Dj-00@usw-sf-web2.sourceforge.net>

Bugs item #566238, was opened at 2002-06-08 17:29
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=566238&group_id=10127

Category: Build control
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Rolf Ade (pointsman)
Assigned to: Greg Stein (gstein)
Summary: 1.95.3: xmlwf startup time much longer

Initial Comment:

At least at my linux box, I seems that the new way of
starting xmlwf - with a shell wrapper - heavily
increases the startup time of xmlwf.

For most people, this may be a really minor problem (it
isn't even a big one for me, though). But if you check
a lot of really small xml files with xmlwf in  one
commandline or a shell script, this is very notable. 

I've noticed it, while checking the (very small) test
files of the OASIS test suite. My shell scripts, that
does this, needed up to 10 times (!) longer, to finished.

To be sure, it's really the startup time, I checked
xmlwf against some bigger XML files (around 30 Mbyte)
and found only minor speed differences between 1.95.2
and 1.95.3. It seems, 1.95.3 is around 6 or 7 percent
slower than 1.95.2 (I've substracted the mesured longer
startup time of the 1.95.3 xmlwf from the running time,
befor calculation.)

rolf


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

>Comment By: Rolf Ade (pointsman)
Date: 2002-07-12 21:45

Message:
Logged In: YES 
user_id=13222


Fred,

you're of course right, the general slowdown is a seperate
issue. I'll open a seperate bug report for this.

To confirm this cleary, the xmlwf startup time is definitely
a non-issue (there was nothing to solve, right from the start.)

I just not noticed that. This time, my habit, to test
software, befor I install it system wide has bitten me :-(.

Again, sorry for any wasted time.

rolf


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-12 20:02

Message:
Logged In: YES 
user_id=3066

Rolf,

I think general slowdown is a separate issue from xmlwf
startup time, which appears to be either solved or a
non-issue at this point.

Would you be interested in doing some "regression
benchmarking" and possibly gathering profiling data to see
what portions of Expat are exhibiting the most change?

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

Comment By: Rolf Ade (pointsman)
Date: 2002-07-12 15:20

Message:
Logged In: YES 
user_id=13222

Greg,

well, you got me. Yes, I observed the slowdown of xmlwf,
while running it from the build copy. Yes, after
installation, there isn't a shell wrapper anymore, just the
xmlwf binary. I'm sorry about any irritation, I've triggered.

But - not to distract from my mistake, but because I'm
really a bit worried about - even beside this shell wrapper
thing (which is not a problem, I confirm)  expat is getting
slower and slower, from version to version. It's not
dramatic, but it sums up.

I've just done some tests, that confirmed that again. To
give some concrete numbers (on a linux 2.2.13, PII 333MHz,
384 MByte memory) from checking a around 100 MByte big XML
file with the according xmlwf tools (I ensured, that the
file is in the system cache)

With 1.92.3:

real    0m12.108s
user    0m11.360s
sys     0m0.660s

With 1.92.2:

real    0m11.152s
user    0m10.450s
sys     0m.670s

With James Clarks 1.2final:

real    0m9.471s
user    0m9.360s
sys     0m0.090s

This numbers are typical for all XML files, I've done this
comparson. To sum up the results, this is a solid 25 percent
slow down from 1.2 to 1.92.3.

Remarkable is the much greater sys part for the 1.92.x
versions. This may because of changed I/O code in the xmlwf
tool (haven't check this). But even  without this, there's a
notable slow down.

It's not dramatic, as said. Expat is still the fastest
compliant XML parser, I know. But to say it frankly, one of
the major points of using expat (if not the major point) is
simply its speed.

Some slow down may be unavoidable (for example due to the
reasent fix for better detection of invalid XML chars), but
I would love, if someone checks this - and the speed of
current versions in general - with a critical eye.

rolf


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

Comment By: Greg Stein (gstein)
Date: 2002-07-11 17:10

Message:
Logged In: YES 
user_id=6501

Rolf,

Was your slower time measured against xmlwf out of the build
tree, or an installed copy? As far as I can tell, we never
install the shell script wrapper. Within the build tree, it
will always be present (the first run will be slow while it
links, then it should be faster (but not as fast as without
the shell script, of course))

Anyways... we need to find out if your observation was for
the build or installed copy of xmlwf.

thx.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-29 15:28

Message:
Logged In: YES 
user_id=3066

This is painful, but not enough to hold up a bugfix release.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-26 04:58

Message:
Logged In: YES 
user_id=3066

Ugh!  This is heinous!  The crufty libtool wrapper should
never be installed, and even says so itself.

Greg, can you fix this soon?

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

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


From noreply@sourceforge.net  Fri Jul 12 18:03:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 17:03:18 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17T88f-0004We-00@usw-sf-web4.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 04:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ari Johnson (ari_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

>Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:39

Message:
Logged In: YES 
user_id=90811

No, my file size is not a multiple of 1024.  Also, as my 
file's name implies and you probably guessed from the 
jabber.xml file I'm using for testing, I intend to use this 
code over a network to communicate with a Jabber 
server.  So I absolutely can't predict my file size in 
advance.  However, I see the oversight you're pointing 
out and will correct it; that's not where this bug is 
coming from, though.

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:34

Message:
Logged In: YES 
user_id=90811

Forgot about my platform-specific code...in test.c, 
change 'stdin->_file' to '0' and 'stdout->_file' to '1'.  
And to run it, ./test < jabber.xml > output.xml


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 16:31

Message:
Logged In: YES 
user_id=290026

Another thought:

If your file size is a multiple of 1024, your code will
call XML_ParseBuffer twice with a buffer size of zero.

This is probably not what is was intended for.
If your file size happens to be like that, maybe you
could try another approach?

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:28

Message:
Logged In: YES 
user_id=90811

I've narrowed the problem down considerably...

I had XML_ParseBuffer() print out 'start' to stderr after it 
sets start in the first bit of the function.  What I found is 
that the contents are correct, for example if I set my 
buffer to equal "<!-- this is a comment -->", then that 
string gets appended to the end of the buffer where it 
should be.  However, start still points to the beginning 
of the previous segment of the buffered text.  This is 
only apparently happening on the call to 
XML_ParseBuffer() after the call that doesn't use the full 
size of the buffer.

Attached, please find a .tar.gz (warning, no directory 
structure, but only 4 files so it shouldn't cause a mess 
for you) with the actual code I'm using.  You'll have to 
compile test.c and xmlstream.c manually and then link 
them to form an executable.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 16:15

Message:
Logged In: YES 
user_id=290026

Since I cannot duplicate this, do you have access
to another platform/OS and can you try it there?
Maybe it is related to the fact that you are compiling
and running this on your version of FreeBSD.



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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:04

Message:
Logged In: YES 
user_id=90811

It doesn't matter what size buffer I request, the 
XML_ParseBuffer() call ends up re-parsing the previous 
buffer when I give it a zero size argument.  Also, even if 
I feed it a fictitious XML comment, it still gives me the 
error 9 - junk after document element.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 15:37

Message:
Logged In: YES 
user_id=290026

Try removing the call for getting a zero sized buffer:
  char *buff = XML_GetBuffer(p, 0);
or change the size parameter back to 1024.
Does that have any effect?


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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:29

Message:
Logged In: YES 
user_id=90811

Just an update...the same thing happens when I don't 
set isFinal in the error-producing call, or of course if I 
feed it more text (since this is just after the </root> tag 
has been read).

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:10

Message:
Logged In: YES 
user_id=90811

I apologize for a mistake; the error it returns is 9 -> 
junk after document element.  I was calling 
GetErrorCode wrong.  Anyhow...

---
int c = 1024;
while(c == 1024) {
  char *buff = XML_GetBuffer(p, 1024);
  if(!buff)
    ...
  c = read(fd, buff, 1024);
  if(c < 0)
    ...
  if(!XML_ParseBuffer(p, c, 0))
    ...
}

...

void handle_end_element(...) {
  if([it was the root element]) {
    char *buff = XML_GetBuffer(p, 0);
    if(!XML_ParseBuffer(p, 0, 1))
      /* This is where the error occurs. */
  }
}


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 14:42

Message:
Logged In: YES 
user_id=290026

In that case please post a small example that can
produce the behaviour you have reported.

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 14:22

Message:
Logged In: YES 
user_id=90811

Same thing occurs with the current CVS.  This even 
occurs when I actually send XML_Parse*() some text to 
process.  And to make things worse, XML_Parse() 
returns false since it's trying to parse text past the close 
tag of my root element, but the error code is set to 0.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:07

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 07:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

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


From noreply@sourceforge.net  Fri Jul 12 18:08:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 17:08:24 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17T7xn-0004C4-00@usw-sf-web4.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 04:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ari Johnson (ari_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

>Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:28

Message:
Logged In: YES 
user_id=90811

I've narrowed the problem down considerably...

I had XML_ParseBuffer() print out 'start' to stderr after it 
sets start in the first bit of the function.  What I found is 
that the contents are correct, for example if I set my 
buffer to equal "<!-- this is a comment -->", then that 
string gets appended to the end of the buffer where it 
should be.  However, start still points to the beginning 
of the previous segment of the buffered text.  This is 
only apparently happening on the call to 
XML_ParseBuffer() after the call that doesn't use the full 
size of the buffer.

Attached, please find a .tar.gz (warning, no directory 
structure, but only 4 files so it shouldn't cause a mess 
for you) with the actual code I'm using.  You'll have to 
compile test.c and xmlstream.c manually and then link 
them to form an executable.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 16:15

Message:
Logged In: YES 
user_id=290026

Since I cannot duplicate this, do you have access
to another platform/OS and can you try it there?
Maybe it is related to the fact that you are compiling
and running this on your version of FreeBSD.



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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:04

Message:
Logged In: YES 
user_id=90811

It doesn't matter what size buffer I request, the 
XML_ParseBuffer() call ends up re-parsing the previous 
buffer when I give it a zero size argument.  Also, even if 
I feed it a fictitious XML comment, it still gives me the 
error 9 - junk after document element.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 15:37

Message:
Logged In: YES 
user_id=290026

Try removing the call for getting a zero sized buffer:
  char *buff = XML_GetBuffer(p, 0);
or change the size parameter back to 1024.
Does that have any effect?


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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:29

Message:
Logged In: YES 
user_id=90811

Just an update...the same thing happens when I don't 
set isFinal in the error-producing call, or of course if I 
feed it more text (since this is just after the </root> tag 
has been read).

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:10

Message:
Logged In: YES 
user_id=90811

I apologize for a mistake; the error it returns is 9 -> 
junk after document element.  I was calling 
GetErrorCode wrong.  Anyhow...

---
int c = 1024;
while(c == 1024) {
  char *buff = XML_GetBuffer(p, 1024);
  if(!buff)
    ...
  c = read(fd, buff, 1024);
  if(c < 0)
    ...
  if(!XML_ParseBuffer(p, c, 0))
    ...
}

...

void handle_end_element(...) {
  if([it was the root element]) {
    char *buff = XML_GetBuffer(p, 0);
    if(!XML_ParseBuffer(p, 0, 1))
      /* This is where the error occurs. */
  }
}


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 14:42

Message:
Logged In: YES 
user_id=290026

In that case please post a small example that can
produce the behaviour you have reported.

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 14:22

Message:
Logged In: YES 
user_id=90811

Same thing occurs with the current CVS.  This even 
occurs when I actually send XML_Parse*() some text to 
process.  And to make things worse, XML_Parse() 
returns false since it's trying to parse text past the close 
tag of my root element, but the error code is set to 0.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:07

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 07:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

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


From noreply@sourceforge.net  Fri Jul 12 22:20:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 21:20:28 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17TENm-0001mj-00@usw-sf-web4.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 05:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ari Johnson (ari_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-13 00:19

Message:
Logged In: YES 
user_id=290026

Without running your code, just by looking at it:

You are not supposed to call XML_GetBuffer or 
XML_ParseBuffer from within a handler 
(xml_handle_endelement in your case).

Take it out and then try again.
I have a suspicion that that might help.

Karl



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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:39

Message:
Logged In: YES 
user_id=90811

No, my file size is not a multiple of 1024.  Also, as my 
file's name implies and you probably guessed from the 
jabber.xml file I'm using for testing, I intend to use this 
code over a network to communicate with a Jabber 
server.  So I absolutely can't predict my file size in 
advance.  However, I see the oversight you're pointing 
out and will correct it; that's not where this bug is 
coming from, though.

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:34

Message:
Logged In: YES 
user_id=90811

Forgot about my platform-specific code...in test.c, 
change 'stdin->_file' to '0' and 'stdout->_file' to '1'.  
And to run it, ./test < jabber.xml > output.xml


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 17:31

Message:
Logged In: YES 
user_id=290026

Another thought:

If your file size is a multiple of 1024, your code will
call XML_ParseBuffer twice with a buffer size of zero.

This is probably not what is was intended for.
If your file size happens to be like that, maybe you
could try another approach?

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:28

Message:
Logged In: YES 
user_id=90811

I've narrowed the problem down considerably...

I had XML_ParseBuffer() print out 'start' to stderr after it 
sets start in the first bit of the function.  What I found is 
that the contents are correct, for example if I set my 
buffer to equal "<!-- this is a comment -->", then that 
string gets appended to the end of the buffer where it 
should be.  However, start still points to the beginning 
of the previous segment of the buffered text.  This is 
only apparently happening on the call to 
XML_ParseBuffer() after the call that doesn't use the full 
size of the buffer.

Attached, please find a .tar.gz (warning, no directory 
structure, but only 4 files so it shouldn't cause a mess 
for you) with the actual code I'm using.  You'll have to 
compile test.c and xmlstream.c manually and then link 
them to form an executable.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 17:15

Message:
Logged In: YES 
user_id=290026

Since I cannot duplicate this, do you have access
to another platform/OS and can you try it there?
Maybe it is related to the fact that you are compiling
and running this on your version of FreeBSD.



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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:04

Message:
Logged In: YES 
user_id=90811

It doesn't matter what size buffer I request, the 
XML_ParseBuffer() call ends up re-parsing the previous 
buffer when I give it a zero size argument.  Also, even if 
I feed it a fictitious XML comment, it still gives me the 
error 9 - junk after document element.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 16:37

Message:
Logged In: YES 
user_id=290026

Try removing the call for getting a zero sized buffer:
  char *buff = XML_GetBuffer(p, 0);
or change the size parameter back to 1024.
Does that have any effect?


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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:29

Message:
Logged In: YES 
user_id=90811

Just an update...the same thing happens when I don't 
set isFinal in the error-producing call, or of course if I 
feed it more text (since this is just after the </root> tag 
has been read).

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:10

Message:
Logged In: YES 
user_id=90811

I apologize for a mistake; the error it returns is 9 -> 
junk after document element.  I was calling 
GetErrorCode wrong.  Anyhow...

---
int c = 1024;
while(c == 1024) {
  char *buff = XML_GetBuffer(p, 1024);
  if(!buff)
    ...
  c = read(fd, buff, 1024);
  if(c < 0)
    ...
  if(!XML_ParseBuffer(p, c, 0))
    ...
}

...

void handle_end_element(...) {
  if([it was the root element]) {
    char *buff = XML_GetBuffer(p, 0);
    if(!XML_ParseBuffer(p, 0, 1))
      /* This is where the error occurs. */
  }
}


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 15:42

Message:
Logged In: YES 
user_id=290026

In that case please post a small example that can
produce the behaviour you have reported.

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:22

Message:
Logged In: YES 
user_id=90811

Same thing occurs with the current CVS.  This even 
occurs when I actually send XML_Parse*() some text to 
process.  And to make things worse, XML_Parse() 
returns false since it's trying to parse text past the close 
tag of my root element, but the error code is set to 0.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 09:07

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

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


From noreply@sourceforge.net  Fri Jul 12 23:04:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 22:04:02 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17TF3i-00018F-00@usw-sf-web3.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 04:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ari Johnson (ari_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

>Comment By: Ari Johnson (ari_j)
Date: 2002-07-13 00:03

Message:
Logged In: YES 
user_id=90811

That worked, thanks!  Maybe you should make a very 
blatant note of that in the reference for all of 
XML_GetBuffer(), XML_ParseBuffer(), and XML_Parse(), as 
well as any other functions that have that requirement.  
Thanks again for the help, and the great library.  It's 
saving me from the bloat. ;)

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 23:19

Message:
Logged In: YES 
user_id=290026

Without running your code, just by looking at it:

You are not supposed to call XML_GetBuffer or 
XML_ParseBuffer from within a handler 
(xml_handle_endelement in your case).

Take it out and then try again.
I have a suspicion that that might help.

Karl



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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:39

Message:
Logged In: YES 
user_id=90811

No, my file size is not a multiple of 1024.  Also, as my 
file's name implies and you probably guessed from the 
jabber.xml file I'm using for testing, I intend to use this 
code over a network to communicate with a Jabber 
server.  So I absolutely can't predict my file size in 
advance.  However, I see the oversight you're pointing 
out and will correct it; that's not where this bug is 
coming from, though.

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:34

Message:
Logged In: YES 
user_id=90811

Forgot about my platform-specific code...in test.c, 
change 'stdin->_file' to '0' and 'stdout->_file' to '1'.  
And to run it, ./test < jabber.xml > output.xml


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 16:31

Message:
Logged In: YES 
user_id=290026

Another thought:

If your file size is a multiple of 1024, your code will
call XML_ParseBuffer twice with a buffer size of zero.

This is probably not what is was intended for.
If your file size happens to be like that, maybe you
could try another approach?

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:28

Message:
Logged In: YES 
user_id=90811

I've narrowed the problem down considerably...

I had XML_ParseBuffer() print out 'start' to stderr after it 
sets start in the first bit of the function.  What I found is 
that the contents are correct, for example if I set my 
buffer to equal "<!-- this is a comment -->", then that 
string gets appended to the end of the buffer where it 
should be.  However, start still points to the beginning 
of the previous segment of the buffered text.  This is 
only apparently happening on the call to 
XML_ParseBuffer() after the call that doesn't use the full 
size of the buffer.

Attached, please find a .tar.gz (warning, no directory 
structure, but only 4 files so it shouldn't cause a mess 
for you) with the actual code I'm using.  You'll have to 
compile test.c and xmlstream.c manually and then link 
them to form an executable.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 16:15

Message:
Logged In: YES 
user_id=290026

Since I cannot duplicate this, do you have access
to another platform/OS and can you try it there?
Maybe it is related to the fact that you are compiling
and running this on your version of FreeBSD.



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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:04

Message:
Logged In: YES 
user_id=90811

It doesn't matter what size buffer I request, the 
XML_ParseBuffer() call ends up re-parsing the previous 
buffer when I give it a zero size argument.  Also, even if 
I feed it a fictitious XML comment, it still gives me the 
error 9 - junk after document element.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 15:37

Message:
Logged In: YES 
user_id=290026

Try removing the call for getting a zero sized buffer:
  char *buff = XML_GetBuffer(p, 0);
or change the size parameter back to 1024.
Does that have any effect?


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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:29

Message:
Logged In: YES 
user_id=90811

Just an update...the same thing happens when I don't 
set isFinal in the error-producing call, or of course if I 
feed it more text (since this is just after the </root> tag 
has been read).

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:10

Message:
Logged In: YES 
user_id=90811

I apologize for a mistake; the error it returns is 9 -> 
junk after document element.  I was calling 
GetErrorCode wrong.  Anyhow...

---
int c = 1024;
while(c == 1024) {
  char *buff = XML_GetBuffer(p, 1024);
  if(!buff)
    ...
  c = read(fd, buff, 1024);
  if(c < 0)
    ...
  if(!XML_ParseBuffer(p, c, 0))
    ...
}

...

void handle_end_element(...) {
  if([it was the root element]) {
    char *buff = XML_GetBuffer(p, 0);
    if(!XML_ParseBuffer(p, 0, 1))
      /* This is where the error occurs. */
  }
}


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 14:42

Message:
Logged In: YES 
user_id=290026

In that case please post a small example that can
produce the behaviour you have reported.

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 14:22

Message:
Logged In: YES 
user_id=90811

Same thing occurs with the current CVS.  This even 
occurs when I actually send XML_Parse*() some text to 
process.  And to make things worse, XML_Parse() 
returns false since it's trying to parse text past the close 
tag of my root element, but the error code is set to 0.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:07

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 07:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

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


From noreply@sourceforge.net  Fri Jul 12 23:10:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 22:10:02 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17TF9b-0001II-00@usw-sf-web1.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 05:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: None
Group: None
Status: Open
>Resolution: Rejected
Priority: 5
Submitted By: Ari Johnson (ari_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-13 01:09

Message:
Logged In: YES 
user_id=290026

Great!
I think you are right - we should add a note to those
functions about when *not* to call them.

I leave this bug report open, so that we don't forget.
I am sure once Fred gets annoyed by the open bug
report he will read this note. <g>

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-13 01:03

Message:
Logged In: YES 
user_id=90811

That worked, thanks!  Maybe you should make a very 
blatant note of that in the reference for all of 
XML_GetBuffer(), XML_ParseBuffer(), and XML_Parse(), as 
well as any other functions that have that requirement.  
Thanks again for the help, and the great library.  It's 
saving me from the bloat. ;)

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-13 00:19

Message:
Logged In: YES 
user_id=290026

Without running your code, just by looking at it:

You are not supposed to call XML_GetBuffer or 
XML_ParseBuffer from within a handler 
(xml_handle_endelement in your case).

Take it out and then try again.
I have a suspicion that that might help.

Karl



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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:39

Message:
Logged In: YES 
user_id=90811

No, my file size is not a multiple of 1024.  Also, as my 
file's name implies and you probably guessed from the 
jabber.xml file I'm using for testing, I intend to use this 
code over a network to communicate with a Jabber 
server.  So I absolutely can't predict my file size in 
advance.  However, I see the oversight you're pointing 
out and will correct it; that's not where this bug is 
coming from, though.

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:34

Message:
Logged In: YES 
user_id=90811

Forgot about my platform-specific code...in test.c, 
change 'stdin->_file' to '0' and 'stdout->_file' to '1'.  
And to run it, ./test < jabber.xml > output.xml


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 17:31

Message:
Logged In: YES 
user_id=290026

Another thought:

If your file size is a multiple of 1024, your code will
call XML_ParseBuffer twice with a buffer size of zero.

This is probably not what is was intended for.
If your file size happens to be like that, maybe you
could try another approach?

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:28

Message:
Logged In: YES 
user_id=90811

I've narrowed the problem down considerably...

I had XML_ParseBuffer() print out 'start' to stderr after it 
sets start in the first bit of the function.  What I found is 
that the contents are correct, for example if I set my 
buffer to equal "<!-- this is a comment -->", then that 
string gets appended to the end of the buffer where it 
should be.  However, start still points to the beginning 
of the previous segment of the buffered text.  This is 
only apparently happening on the call to 
XML_ParseBuffer() after the call that doesn't use the full 
size of the buffer.

Attached, please find a .tar.gz (warning, no directory 
structure, but only 4 files so it shouldn't cause a mess 
for you) with the actual code I'm using.  You'll have to 
compile test.c and xmlstream.c manually and then link 
them to form an executable.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 17:15

Message:
Logged In: YES 
user_id=290026

Since I cannot duplicate this, do you have access
to another platform/OS and can you try it there?
Maybe it is related to the fact that you are compiling
and running this on your version of FreeBSD.



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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:04

Message:
Logged In: YES 
user_id=90811

It doesn't matter what size buffer I request, the 
XML_ParseBuffer() call ends up re-parsing the previous 
buffer when I give it a zero size argument.  Also, even if 
I feed it a fictitious XML comment, it still gives me the 
error 9 - junk after document element.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 16:37

Message:
Logged In: YES 
user_id=290026

Try removing the call for getting a zero sized buffer:
  char *buff = XML_GetBuffer(p, 0);
or change the size parameter back to 1024.
Does that have any effect?


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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:29

Message:
Logged In: YES 
user_id=90811

Just an update...the same thing happens when I don't 
set isFinal in the error-producing call, or of course if I 
feed it more text (since this is just after the </root> tag 
has been read).

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:10

Message:
Logged In: YES 
user_id=90811

I apologize for a mistake; the error it returns is 9 -> 
junk after document element.  I was calling 
GetErrorCode wrong.  Anyhow...

---
int c = 1024;
while(c == 1024) {
  char *buff = XML_GetBuffer(p, 1024);
  if(!buff)
    ...
  c = read(fd, buff, 1024);
  if(c < 0)
    ...
  if(!XML_ParseBuffer(p, c, 0))
    ...
}

...

void handle_end_element(...) {
  if([it was the root element]) {
    char *buff = XML_GetBuffer(p, 0);
    if(!XML_ParseBuffer(p, 0, 1))
      /* This is where the error occurs. */
  }
}


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 15:42

Message:
Logged In: YES 
user_id=290026

In that case please post a small example that can
produce the behaviour you have reported.

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:22

Message:
Logged In: YES 
user_id=90811

Same thing occurs with the current CVS.  This even 
occurs when I actually send XML_Parse*() some text to 
process.  And to make things worse, XML_Parse() 
returns false since it's trying to parse text past the close 
tag of my root element, but the error code is set to 0.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 09:07

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

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


From noreply@sourceforge.net  Sat Jul 13 00:11:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 12 23:11:02 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17TG6V-0002CS-00@usw-sf-web1.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 04:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Ari Johnson (ari_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

>Comment By: Ari Johnson (ari_j)
Date: 2002-07-13 01:10

Message:
Logged In: YES 
user_id=90811

A documentation bug...my favorite kind.  Of course, you 
could always do the more malevolent fix, which would 
be to have XML_GetBuffer() return 0xd00d and 
XML_ParseBuffer() return error with message 'you 
blithering idiot, you can't do that!'.  Of course, 
XML_Parse() would not be changed at all, so people who 
use it would automatically get the core dump for 
accessing memory at 0xd00d.

Then again, that probably only works for my users.  
Some people aren't so tolerant. ;)

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-13 00:09

Message:
Logged In: YES 
user_id=290026

Great!
I think you are right - we should add a note to those
functions about when *not* to call them.

I leave this bug report open, so that we don't forget.
I am sure once Fred gets annoyed by the open bug
report he will read this note. <g>

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-13 00:03

Message:
Logged In: YES 
user_id=90811

That worked, thanks!  Maybe you should make a very 
blatant note of that in the reference for all of 
XML_GetBuffer(), XML_ParseBuffer(), and XML_Parse(), as 
well as any other functions that have that requirement.  
Thanks again for the help, and the great library.  It's 
saving me from the bloat. ;)

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 23:19

Message:
Logged In: YES 
user_id=290026

Without running your code, just by looking at it:

You are not supposed to call XML_GetBuffer or 
XML_ParseBuffer from within a handler 
(xml_handle_endelement in your case).

Take it out and then try again.
I have a suspicion that that might help.

Karl



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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:39

Message:
Logged In: YES 
user_id=90811

No, my file size is not a multiple of 1024.  Also, as my 
file's name implies and you probably guessed from the 
jabber.xml file I'm using for testing, I intend to use this 
code over a network to communicate with a Jabber 
server.  So I absolutely can't predict my file size in 
advance.  However, I see the oversight you're pointing 
out and will correct it; that's not where this bug is 
coming from, though.

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:34

Message:
Logged In: YES 
user_id=90811

Forgot about my platform-specific code...in test.c, 
change 'stdin->_file' to '0' and 'stdout->_file' to '1'.  
And to run it, ./test < jabber.xml > output.xml


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 16:31

Message:
Logged In: YES 
user_id=290026

Another thought:

If your file size is a multiple of 1024, your code will
call XML_ParseBuffer twice with a buffer size of zero.

This is probably not what is was intended for.
If your file size happens to be like that, maybe you
could try another approach?

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:28

Message:
Logged In: YES 
user_id=90811

I've narrowed the problem down considerably...

I had XML_ParseBuffer() print out 'start' to stderr after it 
sets start in the first bit of the function.  What I found is 
that the contents are correct, for example if I set my 
buffer to equal "<!-- this is a comment -->", then that 
string gets appended to the end of the buffer where it 
should be.  However, start still points to the beginning 
of the previous segment of the buffered text.  This is 
only apparently happening on the call to 
XML_ParseBuffer() after the call that doesn't use the full 
size of the buffer.

Attached, please find a .tar.gz (warning, no directory 
structure, but only 4 files so it shouldn't cause a mess 
for you) with the actual code I'm using.  You'll have to 
compile test.c and xmlstream.c manually and then link 
them to form an executable.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 16:15

Message:
Logged In: YES 
user_id=290026

Since I cannot duplicate this, do you have access
to another platform/OS and can you try it there?
Maybe it is related to the fact that you are compiling
and running this on your version of FreeBSD.



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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:04

Message:
Logged In: YES 
user_id=90811

It doesn't matter what size buffer I request, the 
XML_ParseBuffer() call ends up re-parsing the previous 
buffer when I give it a zero size argument.  Also, even if 
I feed it a fictitious XML comment, it still gives me the 
error 9 - junk after document element.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 15:37

Message:
Logged In: YES 
user_id=290026

Try removing the call for getting a zero sized buffer:
  char *buff = XML_GetBuffer(p, 0);
or change the size parameter back to 1024.
Does that have any effect?


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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:29

Message:
Logged In: YES 
user_id=90811

Just an update...the same thing happens when I don't 
set isFinal in the error-producing call, or of course if I 
feed it more text (since this is just after the </root> tag 
has been read).

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:10

Message:
Logged In: YES 
user_id=90811

I apologize for a mistake; the error it returns is 9 -> 
junk after document element.  I was calling 
GetErrorCode wrong.  Anyhow...

---
int c = 1024;
while(c == 1024) {
  char *buff = XML_GetBuffer(p, 1024);
  if(!buff)
    ...
  c = read(fd, buff, 1024);
  if(c < 0)
    ...
  if(!XML_ParseBuffer(p, c, 0))
    ...
}

...

void handle_end_element(...) {
  if([it was the root element]) {
    char *buff = XML_GetBuffer(p, 0);
    if(!XML_ParseBuffer(p, 0, 1))
      /* This is where the error occurs. */
  }
}


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 14:42

Message:
Logged In: YES 
user_id=290026

In that case please post a small example that can
produce the behaviour you have reported.

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 14:22

Message:
Logged In: YES 
user_id=90811

Same thing occurs with the current CVS.  This even 
occurs when I actually send XML_Parse*() some text to 
process.  And to make things worse, XML_Parse() 
returns false since it's trying to parse text past the close 
tag of my root element, but the error code is set to 0.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:07

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 07:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

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


From noreply@sourceforge.net  Sat Jul 13 13:09:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat Jul 13 12:09:09 2002
Subject: [ expat-Patches-581069 ] Borland build files ver 1.95.4
Message-ID: <E17TSFZ-0003lM-00@usw-sf-web3.sourceforge.net>

Patches item #581069, was opened at 2002-07-13 15:08
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=581069&group_id=10127

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Patrick McConnell (pmcconnell)
Assigned to: Nobody/Anonymous (nobody)
Summary: Borland build files ver 1.95.4

Initial Comment:
The Borland project and make files included with 
vesion 1.95.4 contain 2 errors that prevent them from 
working. To fix this, delete all files in the 
expat\Source\BCB5 directory and replace them with 
the attached files.

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

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


From noreply@sourceforge.net  Sat Jul 13 15:00:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat Jul 13 14:00:01 2002
Subject: [ expat-Patches-458907 ] config.h appears to be unused
Message-ID: <E17TTyt-00084S-00@usw-sf-web1.sourceforge.net>

Patches item #458907, was opened at 2001-09-05 14:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=458907&group_id=10127

Category: Build Control
Group: None
>Status: Pending
Resolution: Out of Date
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Greg Stein (gstein)
Summary: config.h appears to be unused

Initial Comment:
To compile expat as part of another package (e.g. 
PyXML), the expat configure might not have been run. 
For that kind of application, it is necessary to wrap 
each occurrence of config.h into HAVE_CONFIG_H; the 
attached patch does that.

While trying to figure out which of the defines are 
needed, it appears that none of them are (i.e. HAVE_ 
is never used). For stand-along compilation, I found 
that only VERSION, XML_NS, XML_DTD, XML_BYTE_ORDER, 
and XML_CONTEXT_BYTES must be defined. Is that 
impression correct?


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

>Comment By: Greg Stein (gstein)
Date: 2002-07-13 13:59

Message:
Logged In: YES 
user_id=6501

I don't see how we could operate in the "no config" case. 
We *do* require some of those configuration variables, as 
you originally pointed out. Thus, you need expat_config.h 
from somewhere.

On the Windows platform, we hand-built the file and include 
it as winconfig.h. But we *do* have a config header in that 
case.
(and my preference would be to call it expat_config.hw and 
have the .dsp copy it over to the .h file; thus, we couldn't 
need to set or test COMPILED_FROM_DSP; just need to 
get to this at some point (it is now APR, APRUTIL, and SVN 
handle config on windows))

Further, I don't see how you can avoid running configure. 
We need to do that to create a Makefile (and 
expat_config.h, of course). And the precursor to running 
configure is to run buildconf.

When APR or APRUTIL are embedded into apps (Apache 
httpd or SVN), we run their buildconf (during release 
packaging) and we run their configure (at end-user config 
time; we run it from the app's configure). In my mind, if you 
are creating a library package to be embedded, then it is 
considered an opaque blob: you interact with it according 
to its defined mechanism. If you want to shortcut the 
system, then you're assuming too much knowledge about 
the library.

(I thought xmlwf used the MMAP stuff, but it doesn't; we 
just select a different .c file at config time; however, it does 
use HAVE_UNISTD_H and it should be using a lot more, 
such as HAVE_STRING_H or HAVE_STDDEF_H and 
whatnot; xmlparse.c and brethren should be, too, for that 
matter (e.g. some platforms have string.h and others 
strings.h))

Personally, I don't understand the HAVE_CONFIG_H thing. 
I'm presuming that is mostly because of past conflicts with 
everybody naming their file config.h. It meant you couldn't 
have several config.h files in use. But even then: how could 
an app get the defines it needs? Did the embedding app 
have to define a billion things on their CC command line? 
Man... talk about needing to *really* know about the 
internals of your embedded library. Our use of 
expat_config.h solves these historical conflicts.

And regarding the elimination of unneeded symbols: those 
are automatically generated by autoheader. We don't have 
control over the full set in there. In the past, it was possible 
to use acconfig.h to have fine-grained control over the 
contents, but much of that framework is deprecated. And it 
isn't really needed, in any case, since there isn't any real 
harm in letting autoheader just build one for us, with 
whatever it thinks is needed.

Let me turn the question around: why is it a problem for the 
parent application to run buildconf at packaging time, and 
to run Expat's configure at parent-configure time? It seems 
to work just fine for me, whenever I embed a library (APR
(UTIL), Expat, Neon, and Berkeley DB) into another app.

Changing status to Pending.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-12 05:09

Message:
Logged In: YES 
user_id=3066

This has come up as still being a problem for a couple of 
projects on the Python XML-SIG, so this needs to be 
reconsidered.

Hopefully Martin will be interested in checking and updating 
his proposed patch against 1.95.4.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 02:15

Message:
Logged In: YES 
user_id=21627

Can you elaborate which defines of  expat_config.h is used
in xmlwf? I could not find any.

Why is it wrong to not run configure? autoconf packages,
historically, always supported "manual" configuration, by
editing config.h manually. Also,  your own build process
does not use expat_config.h if COMPILED_FROM_DSP is set. In
general, it is not possible to run configure if you don't
have /bin/sh on a system; this is a scenario that PyXML
needs to support.

Also, traditionally, autoconf supports both configuration
with and without a config.h; files including config.h would
always wrap this with a

#ifdef HAVE_CONFIG_H

(should be HAVE_EXPAT_CONFIG_H in your case).

All I'm asking is that the combination "manual
configuration" and "no config.h" is supported. If this is
not available, I have to fake-generate a config.h, which is
ugly.

It would also help if config.h was reduced to the set of
defines which are actually used, instead of autoconfiscating
every line of the source.

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

Comment By: Greg Stein (gstein)
Date: 2002-06-01 16:44

Message:
Logged In: YES 
user_id=6501

We may not use most of those (autoconf creates them as part
of searching for particular functions and stuff), but xmlwf
does use some.

That said: if you're going to embed Expat into another
application, then you'll need to adjust things accordingly.
Note that we've switched to "expat_config.h", so it might be
possible to just include that into your own application
since a conflict on config.h won't occur any more.

Also, note that the premise of "not running configure" is
probably quite wrong. Expat is embedded into the ASF's
apr-util project, and we *do* run configure for that, and
build expat as a sub-library. (heck, we even run expat's
buildconf.sh at the appropriate time)

Given the change to expat_config.h, and how I believe
embedding should work, I'm going to close this patch as
rejected. However, even with that said, I'm quite happy to
be corrected and/or to make other changes to simplify
Expat's ability to be embedded.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-30 21:10

Message:
Logged In: YES 
user_id=3066

Greg, can you please respond to this?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-11-08 20:48

Message:
Logged In: YES 
user_id=3066

It certainly looks like it can be reduced and possibly
removed; I'll read up on a few of the autoconf things before
removing it completely.

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

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


From noreply@sourceforge.net  Sun Jul 14 01:42:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun Jul 14 00:42:03 2002
Subject: [ expat-Patches-458907 ] config.h appears to be unused
Message-ID: <E17Te0y-000817-00@usw-sf-web1.sourceforge.net>

Patches item #458907, was opened at 2001-09-05 23:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=458907&group_id=10127

Category: Build Control
Group: None
>Status: Open
Resolution: Out of Date
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Greg Stein (gstein)
Summary: config.h appears to be unused

Initial Comment:
To compile expat as part of another package (e.g. 
PyXML), the expat configure might not have been run. 
For that kind of application, it is necessary to wrap 
each occurrence of config.h into HAVE_CONFIG_H; the 
attached patch does that.

While trying to figure out which of the defines are 
needed, it appears that none of them are (i.e. HAVE_ 
is never used). For stand-along compilation, I found 
that only VERSION, XML_NS, XML_DTD, XML_BYTE_ORDER, 
and XML_CONTEXT_BYTES must be defined. Is that 
impression correct?


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-07-14 09:41

Message:
Logged In: YES 
user_id=21627

Your conclusion is incorrect: that you need the #defines
doesn't mean that you need expat_config.h. Instead, the
configuration variables could also be passed on the compiler
command line.

To support configurations without a expat_config.h, you must
conditionally include the config.h, like

#ifdef HAVE_CONFIG_H
#include "expat_config.h"
#endif

Then, when a configure was run, you define HAVE_CONFIG_H in
the makefile; if configure was not run, you don't define it.
I could accept a negative test, like

#ifndef DONT_HAVE_CONFIG_H
#include "expat_config.h"
#endif

so that I would pass -DDONT_HAVE_CONFIG_H to my compiler
invocations.

Of all the HAVE_ tests in expat_config, only HAVE_BCOPY and
HAVE_MEMMOVE are used in the Expat library; everything else
is unneeded. If I can find out whether memmove is defined by
other means than running configure, I do not need to run
configure (platforms that don't have memmove are of no
interest to me, so I could just always define HAVE_MEMMOVE).

The HAVE_CONFIG_H feature is *not* to avoid clashes with
multiple config.h files; it historically predates the usage
of header files. configure would generate billions of -D
options into the makefile (and still does, if you tell it
that you don't use a config.h file). I want to use a
configuration without config.h, so I kindly request the
number of defines is reduced to those that are actually used.

With autoheader, you do have full control over the set of
symbols in config.h: namely those symbols that configure.in
checks for. For example, if you modify configure.in to not
mention fcntl.h, then autoheader will drop the unused
HAVE_FCNTL_H. 

Unfortunately, libtool.m4 pulls in a number of unneeded
defines (like HAVE_DLFCN_H); others (like getpagesize) are
pulled in through the test for mmap.

So please do consider making expat more friendly for
embedding into environments where configure is not run.

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

Comment By: Greg Stein (gstein)
Date: 2002-07-13 22:59

Message:
Logged In: YES 
user_id=6501

I don't see how we could operate in the "no config" case. 
We *do* require some of those configuration variables, as 
you originally pointed out. Thus, you need expat_config.h 
from somewhere.

On the Windows platform, we hand-built the file and include 
it as winconfig.h. But we *do* have a config header in that 
case.
(and my preference would be to call it expat_config.hw and 
have the .dsp copy it over to the .h file; thus, we couldn't 
need to set or test COMPILED_FROM_DSP; just need to 
get to this at some point (it is now APR, APRUTIL, and SVN 
handle config on windows))

Further, I don't see how you can avoid running configure. 
We need to do that to create a Makefile (and 
expat_config.h, of course). And the precursor to running 
configure is to run buildconf.

When APR or APRUTIL are embedded into apps (Apache 
httpd or SVN), we run their buildconf (during release 
packaging) and we run their configure (at end-user config 
time; we run it from the app's configure). In my mind, if you 
are creating a library package to be embedded, then it is 
considered an opaque blob: you interact with it according 
to its defined mechanism. If you want to shortcut the 
system, then you're assuming too much knowledge about 
the library.

(I thought xmlwf used the MMAP stuff, but it doesn't; we 
just select a different .c file at config time; however, it does 
use HAVE_UNISTD_H and it should be using a lot more, 
such as HAVE_STRING_H or HAVE_STDDEF_H and 
whatnot; xmlparse.c and brethren should be, too, for that 
matter (e.g. some platforms have string.h and others 
strings.h))

Personally, I don't understand the HAVE_CONFIG_H thing. 
I'm presuming that is mostly because of past conflicts with 
everybody naming their file config.h. It meant you couldn't 
have several config.h files in use. But even then: how could 
an app get the defines it needs? Did the embedding app 
have to define a billion things on their CC command line? 
Man... talk about needing to *really* know about the 
internals of your embedded library. Our use of 
expat_config.h solves these historical conflicts.

And regarding the elimination of unneeded symbols: those 
are automatically generated by autoheader. We don't have 
control over the full set in there. In the past, it was possible 
to use acconfig.h to have fine-grained control over the 
contents, but much of that framework is deprecated. And it 
isn't really needed, in any case, since there isn't any real 
harm in letting autoheader just build one for us, with 
whatever it thinks is needed.

Let me turn the question around: why is it a problem for the 
parent application to run buildconf at packaging time, and 
to run Expat's configure at parent-configure time? It seems 
to work just fine for me, whenever I embed a library (APR
(UTIL), Expat, Neon, and Berkeley DB) into another app.

Changing status to Pending.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-12 14:09

Message:
Logged In: YES 
user_id=3066

This has come up as still being a problem for a couple of 
projects on the Python XML-SIG, so this needs to be 
reconsidered.

Hopefully Martin will be interested in checking and updating 
his proposed patch against 1.95.4.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 11:15

Message:
Logged In: YES 
user_id=21627

Can you elaborate which defines of  expat_config.h is used
in xmlwf? I could not find any.

Why is it wrong to not run configure? autoconf packages,
historically, always supported "manual" configuration, by
editing config.h manually. Also,  your own build process
does not use expat_config.h if COMPILED_FROM_DSP is set. In
general, it is not possible to run configure if you don't
have /bin/sh on a system; this is a scenario that PyXML
needs to support.

Also, traditionally, autoconf supports both configuration
with and without a config.h; files including config.h would
always wrap this with a

#ifdef HAVE_CONFIG_H

(should be HAVE_EXPAT_CONFIG_H in your case).

All I'm asking is that the combination "manual
configuration" and "no config.h" is supported. If this is
not available, I have to fake-generate a config.h, which is
ugly.

It would also help if config.h was reduced to the set of
defines which are actually used, instead of autoconfiscating
every line of the source.

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

Comment By: Greg Stein (gstein)
Date: 2002-06-02 01:44

Message:
Logged In: YES 
user_id=6501

We may not use most of those (autoconf creates them as part
of searching for particular functions and stuff), but xmlwf
does use some.

That said: if you're going to embed Expat into another
application, then you'll need to adjust things accordingly.
Note that we've switched to "expat_config.h", so it might be
possible to just include that into your own application
since a conflict on config.h won't occur any more.

Also, note that the premise of "not running configure" is
probably quite wrong. Expat is embedded into the ASF's
apr-util project, and we *do* run configure for that, and
build expat as a sub-library. (heck, we even run expat's
buildconf.sh at the appropriate time)

Given the change to expat_config.h, and how I believe
embedding should work, I'm going to close this patch as
rejected. However, even with that said, I'm quite happy to
be corrected and/or to make other changes to simplify
Expat's ability to be embedded.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-31 06:10

Message:
Logged In: YES 
user_id=3066

Greg, can you please respond to this?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-11-09 05:48

Message:
Logged In: YES 
user_id=3066

It certainly looks like it can be reduced and possibly
removed; I'll read up on a few of the autoconf things before
removing it completely.

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

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


From jbrow@ix.netcom.com  Wed Jul 17 12:03:04 2002
From: jbrow@ix.netcom.com (Jerry Brown)
Date: Wed Jul 17 11:03:04 2002
Subject: expat with Borland
Message-ID: <001101c22dbd$e2e19a60$2900b83f@vaio>

Problem: I could not link the Expat-1.95.3 sample problem using
 Borland C++Builder Personal Version 6.0 [Build 10.158]under
 Windows 98[Build 4.10.1998].

Error message:
[Linker Fatal Error] Fatal: Illegal option: 1.95.3\Libs;
c:\program files\borland\cbuilder6\lib\obj;
c:\program files\borland\cbuilder6\lib;
c:\program files\borland\cbuilder6\lib\release

Linker options:
    <LFLAGS value="-D&quot;&quot; -ap -Tpe -x -Gn -v"/>

Related components:
 The first line of c:\expat-1.95.3\libs\libexpat.lib (6/3/02)
  has: "!<arch>   "; but the first lines in lib files in
  ...CBuilder6/Lib are quite different.

 TLIB 4.5 on this item reports "Error: Bad header in input LIB";
   yet it reports listing requests correctly from Borland lib files.

 Referring to Microsoft and Borland, the book "C++Builder 5 Developer's
  Guide" (SAMS, page 952) states "...for static linking you have a problem
  with the diferent exporting conventions used by the two companies."
  When rebuiling an earlier version of Expat from the CD accompanying
  "C++XML" by Fabio Arciniegas, I did ultimately fail with a crash of the
  executable created with a command-line TLINK32 of obj files created;
  in C++Builder6; and I noticed and worked around linker errors referencing
  symbols with an underscore prefix.

Rebuilding Expat could be assisted by the VCTOBPR.EXE program, which
 converts .DSP or .DSW files (Microsoft project or workspace files) to
 Borland project files, but I do not have this utility.

The file "expat_config.h" is included in "expat.c", yet it is not available
in the
 distributed materials, so rebuilding obj files under the Borland C++Builder
 is not possible.

Also, another error prevents a successful make:
[C++ Fatal Error] xmlparse.c(84): F1003 Error directive: memmove does not
exist
 on this platform, nor is a substitute available




From noreply@sourceforge.net  Wed Jul 17 16:36:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed Jul 17 15:36:04 2002
Subject: [ expat-Bugs-583114 ] 1.95.4 not backward compatible w 1.95.2
Message-ID: <E17UxOh-00006c-00@usw-sf-web5.sourceforge.net>

Bugs item #583114, was opened at 2002-07-18 00:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=583114&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michel Rodriguez (mirod)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.4 not backward compatible w 1.95.2

Initial Comment:
When upgrading from 1.95.2 to 1.95.4 I found that the
behaviour of the library has changed: I can no longer
use a fake (non-existent) DTD to avoid entity
declaration errors.

I found the change using XML::Parser but I would think
it is caused by expat (it happened right after I
upgraded it):

perl -MXML::Parser -e'XML::Parser->new->parse( q{<?xml
version="1.0" standalone="no"?><!DOCTYPE doc SYSTEM
"dummy.dtd">
<doc>
  <elt1>toto &ent1;</elt1>
</doc>});'

gives no error using 1.95.2 but a "undefined entity at
line 3, column 13, byte 90" with 1.95.4

I know that trick is devious and certainly slightly
evil, but I found it quite useful ;--)

The new result might be the proper behaviour but it is
not documented (as far as I could tell) and it
certainly breaks compatibility


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

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


From noreply@sourceforge.net  Wed Jul 17 17:38:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed Jul 17 16:38:04 2002
Subject: [ expat-Bugs-583114 ] 1.95.4 not backward compatible w 1.95.2
Message-ID: <E17UyMq-000486-00@usw-sf-web3.sourceforge.net>

Bugs item #583114, was opened at 2002-07-18 00:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=583114&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michel Rodriguez (mirod)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.4 not backward compatible w 1.95.2

Initial Comment:
When upgrading from 1.95.2 to 1.95.4 I found that the
behaviour of the library has changed: I can no longer
use a fake (non-existent) DTD to avoid entity
declaration errors.

I found the change using XML::Parser but I would think
it is caused by expat (it happened right after I
upgraded it):

perl -MXML::Parser -e'XML::Parser->new->parse( q{<?xml
version="1.0" standalone="no"?><!DOCTYPE doc SYSTEM
"dummy.dtd">
<doc>
  <elt1>toto &ent1;</elt1>
</doc>});'

gives no error using 1.95.2 but a "undefined entity at
line 3, column 13, byte 90" with 1.95.4

I know that trick is devious and certainly slightly
evil, but I found it quite useful ;--)

The new result might be the proper behaviour but it is
not documented (as far as I could tell) and it
certainly breaks compatibility


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

>Comment By: Michel Rodriguez (mirod)
Date: 2002-07-18 01:38

Message:
Logged In: YES 
user_id=72556

I think the bug is actually not due to the library but to
XML::Parser, or at least to XML::Parser's integration with
the library. xmlfw correctly reports that the document is OK
if standalone is set to "no", even with 1.95.4

I will have a look at XML::Parser::Expat but my C is really
rusty :--( 

Thanks

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

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


From noreply@sourceforge.net  Wed Jul 17 17:47:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed Jul 17 16:47:02 2002
Subject: [ expat-Bugs-583114 ] 1.95.4 not backward compatible w 1.95.2
Message-ID: <E17UyUn-0004FL-00@usw-sf-web3.sourceforge.net>

Bugs item #583114, was opened at 2002-07-17 18:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=583114&group_id=10127

Category: None
Group: None
Status: Open
>Resolution: Rejected
Priority: 5
Submitted By: Michel Rodriguez (mirod)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.4 not backward compatible w 1.95.2

Initial Comment:
When upgrading from 1.95.2 to 1.95.4 I found that the
behaviour of the library has changed: I can no longer
use a fake (non-existent) DTD to avoid entity
declaration errors.

I found the change using XML::Parser but I would think
it is caused by expat (it happened right after I
upgraded it):

perl -MXML::Parser -e'XML::Parser->new->parse( q{<?xml
version="1.0" standalone="no"?><!DOCTYPE doc SYSTEM
"dummy.dtd">
<doc>
  <elt1>toto &ent1;</elt1>
</doc>});'

gives no error using 1.95.2 but a "undefined entity at
line 3, column 13, byte 90" with 1.95.4

I know that trick is devious and certainly slightly
evil, but I found it quite useful ;--)

The new result might be the proper behaviour but it is
not documented (as far as I could tell) and it
certainly breaks compatibility


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-17 19:46

Message:
Logged In: YES 
user_id=290026

Michel,

This change of behaviour is due to a bug fix.
Documentation for fixes can be found in the
associated bug and patch reports.

As a matter of fact, this specific fix is even mentioned
in the release notes for 1.95.4: 
Re-implemented WFC: Entity Declared from XML 1.0 spec ...

I am are aware that fixing bugs may introduce 
incompatibilities, but given the alternative of not fixing them ...

Anyway, if this is crucial to you, I recommend you do
not upgrade.

Karl

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

Comment By: Michel Rodriguez (mirod)
Date: 2002-07-17 19:38

Message:
Logged In: YES 
user_id=72556

I think the bug is actually not due to the library but to
XML::Parser, or at least to XML::Parser's integration with
the library. xmlfw correctly reports that the document is OK
if standalone is set to "no", even with 1.95.4

I will have a look at XML::Parser::Expat but my C is really
rusty :--( 

Thanks

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

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


From noreply@sourceforge.net  Wed Jul 17 18:06:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed Jul 17 17:06:23 2002
Subject: [ expat-Bugs-583114 ] 1.95.4 not backward compatible w 1.95.2
Message-ID: <E17Uynj-0004XG-00@usw-sf-web3.sourceforge.net>

Bugs item #583114, was opened at 2002-07-17 18:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=583114&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Michel Rodriguez (mirod)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.4 not backward compatible w 1.95.2

Initial Comment:
When upgrading from 1.95.2 to 1.95.4 I found that the
behaviour of the library has changed: I can no longer
use a fake (non-existent) DTD to avoid entity
declaration errors.

I found the change using XML::Parser but I would think
it is caused by expat (it happened right after I
upgraded it):

perl -MXML::Parser -e'XML::Parser->new->parse( q{<?xml
version="1.0" standalone="no"?><!DOCTYPE doc SYSTEM
"dummy.dtd">
<doc>
  <elt1>toto &ent1;</elt1>
</doc>});'

gives no error using 1.95.2 but a "undefined entity at
line 3, column 13, byte 90" with 1.95.4

I know that trick is devious and certainly slightly
evil, but I found it quite useful ;--)

The new result might be the proper behaviour but it is
not documented (as far as I could tell) and it
certainly breaks compatibility


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-17 20:05

Message:
Logged In: YES 
user_id=290026

Michel,

At closer inspection, this document is not well-formed,
because Expat detects that it actually has no DTD,
assuming that you didn't set an external entity ref handler.

Once there is no DTD, then standalone="no" doesn't matter
anymore, the spec requires &ent1; to be declared.

However, if you set an external entity handler and pass an
empty file to it, then it might work as it did for you before.
The crucial point would be that you need to create an
external entity parser and call it's XML_Parse function,
if I remember correctly.

In any case, on my system here, Expat reports an
undefined entity error.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-17 19:46

Message:
Logged In: YES 
user_id=290026

Michel,

This change of behaviour is due to a bug fix.
Documentation for fixes can be found in the
associated bug and patch reports.

As a matter of fact, this specific fix is even mentioned
in the release notes for 1.95.4: 
Re-implemented WFC: Entity Declared from XML 1.0 spec ...

I am are aware that fixing bugs may introduce 
incompatibilities, but given the alternative of not fixing them ...

Anyway, if this is crucial to you, I recommend you do
not upgrade.

Karl

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

Comment By: Michel Rodriguez (mirod)
Date: 2002-07-17 19:38

Message:
Logged In: YES 
user_id=72556

I think the bug is actually not due to the library but to
XML::Parser, or at least to XML::Parser's integration with
the library. xmlfw correctly reports that the document is OK
if standalone is set to "no", even with 1.95.4

I will have a look at XML::Parser::Expat but my C is really
rusty :--( 

Thanks

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

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


From noreply@sourceforge.net  Wed Jul 17 18:42:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed Jul 17 17:42:04 2002
Subject: [ expat-Bugs-583114 ] 1.95.4 not backward compatible w 1.95.2
Message-ID: <E17UzM7-0005Ct-00@usw-sf-web3.sourceforge.net>

Bugs item #583114, was opened at 2002-07-18 00:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=583114&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Michel Rodriguez (mirod)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.4 not backward compatible w 1.95.2

Initial Comment:
When upgrading from 1.95.2 to 1.95.4 I found that the
behaviour of the library has changed: I can no longer
use a fake (non-existent) DTD to avoid entity
declaration errors.

I found the change using XML::Parser but I would think
it is caused by expat (it happened right after I
upgraded it):

perl -MXML::Parser -e'XML::Parser->new->parse( q{<?xml
version="1.0" standalone="no"?><!DOCTYPE doc SYSTEM
"dummy.dtd">
<doc>
  <elt1>toto &ent1;</elt1>
</doc>});'

gives no error using 1.95.2 but a "undefined entity at
line 3, column 13, byte 90" with 1.95.4

I know that trick is devious and certainly slightly
evil, but I found it quite useful ;--)

The new result might be the proper behaviour but it is
not documented (as far as I could tell) and it
certainly breaks compatibility


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

>Comment By: Michel Rodriguez (mirod)
Date: 2002-07-18 02:41

Message:
Logged In: YES 
user_id=72556

You are right xmlwf  reports an error with this document (I
was using an old version, !@#$%^&* path!)

So my trick does not work any more, too bad, it was quite
convenient. As I use XML::Parser as a base for an other
module (XML::Twig) I can't really control which version of
expat users of the module have installed, so I will just
upgrade the tests (which fail wih 1.95.4), and I might add
an option to use an external entity parser and try to
by-pass the check.

Thanks a lot


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-18 02:05

Message:
Logged In: YES 
user_id=290026

Michel,

At closer inspection, this document is not well-formed,
because Expat detects that it actually has no DTD,
assuming that you didn't set an external entity ref handler.

Once there is no DTD, then standalone="no" doesn't matter
anymore, the spec requires &ent1; to be declared.

However, if you set an external entity handler and pass an
empty file to it, then it might work as it did for you before.
The crucial point would be that you need to create an
external entity parser and call it's XML_Parse function,
if I remember correctly.

In any case, on my system here, Expat reports an
undefined entity error.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-18 01:46

Message:
Logged In: YES 
user_id=290026

Michel,

This change of behaviour is due to a bug fix.
Documentation for fixes can be found in the
associated bug and patch reports.

As a matter of fact, this specific fix is even mentioned
in the release notes for 1.95.4: 
Re-implemented WFC: Entity Declared from XML 1.0 spec ...

I am are aware that fixing bugs may introduce 
incompatibilities, but given the alternative of not fixing them ...

Anyway, if this is crucial to you, I recommend you do
not upgrade.

Karl

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

Comment By: Michel Rodriguez (mirod)
Date: 2002-07-18 01:38

Message:
Logged In: YES 
user_id=72556

I think the bug is actually not due to the library but to
XML::Parser, or at least to XML::Parser's integration with
the library. xmlfw correctly reports that the document is OK
if standalone is set to "no", even with 1.95.4

I will have a look at XML::Parser::Expat but my C is really
rusty :--( 

Thanks

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

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


From noreply@sourceforge.net  Wed Jul 17 20:47:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed Jul 17 19:47:05 2002
Subject: [ expat-Bugs-583114 ] 1.95.4 not backward compatible w 1.95.2
Message-ID: <E17V1JY-0000lB-00@usw-sf-web4.sourceforge.net>

Bugs item #583114, was opened at 2002-07-17 18:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=583114&group_id=10127

Category: None
Group: None
>Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Michel Rodriguez (mirod)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.4 not backward compatible w 1.95.2

Initial Comment:
When upgrading from 1.95.2 to 1.95.4 I found that the
behaviour of the library has changed: I can no longer
use a fake (non-existent) DTD to avoid entity
declaration errors.

I found the change using XML::Parser but I would think
it is caused by expat (it happened right after I
upgraded it):

perl -MXML::Parser -e'XML::Parser->new->parse( q{<?xml
version="1.0" standalone="no"?><!DOCTYPE doc SYSTEM
"dummy.dtd">
<doc>
  <elt1>toto &ent1;</elt1>
</doc>});'

gives no error using 1.95.2 but a "undefined entity at
line 3, column 13, byte 90" with 1.95.4

I know that trick is devious and certainly slightly
evil, but I found it quite useful ;--)

The new result might be the proper behaviour but it is
not documented (as far as I could tell) and it
certainly breaks compatibility


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-17 22:46

Message:
Logged In: YES 
user_id=3066

Rejected reports should be closed.

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

Comment By: Michel Rodriguez (mirod)
Date: 2002-07-17 20:41

Message:
Logged In: YES 
user_id=72556

You are right xmlwf  reports an error with this document (I
was using an old version, !@#$%^&* path!)

So my trick does not work any more, too bad, it was quite
convenient. As I use XML::Parser as a base for an other
module (XML::Twig) I can't really control which version of
expat users of the module have installed, so I will just
upgrade the tests (which fail wih 1.95.4), and I might add
an option to use an external entity parser and try to
by-pass the check.

Thanks a lot


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-17 20:05

Message:
Logged In: YES 
user_id=290026

Michel,

At closer inspection, this document is not well-formed,
because Expat detects that it actually has no DTD,
assuming that you didn't set an external entity ref handler.

Once there is no DTD, then standalone="no" doesn't matter
anymore, the spec requires &ent1; to be declared.

However, if you set an external entity handler and pass an
empty file to it, then it might work as it did for you before.
The crucial point would be that you need to create an
external entity parser and call it's XML_Parse function,
if I remember correctly.

In any case, on my system here, Expat reports an
undefined entity error.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-17 19:46

Message:
Logged In: YES 
user_id=290026

Michel,

This change of behaviour is due to a bug fix.
Documentation for fixes can be found in the
associated bug and patch reports.

As a matter of fact, this specific fix is even mentioned
in the release notes for 1.95.4: 
Re-implemented WFC: Entity Declared from XML 1.0 spec ...

I am are aware that fixing bugs may introduce 
incompatibilities, but given the alternative of not fixing them ...

Anyway, if this is crucial to you, I recommend you do
not upgrade.

Karl

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

Comment By: Michel Rodriguez (mirod)
Date: 2002-07-17 19:38

Message:
Logged In: YES 
user_id=72556

I think the bug is actually not due to the library but to
XML::Parser, or at least to XML::Parser's integration with
the library. xmlfw correctly reports that the document is OK
if standalone is set to "no", even with 1.95.4

I will have a look at XML::Parser::Expat but my C is really
rusty :--( 

Thanks

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

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


From noreply@sourceforge.net  Wed Jul 17 20:52:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed Jul 17 19:52:02 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17V1Nf-0005CB-00@usw-sf-web1.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 05:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

>Category: Documentation
Group: None
Status: Open
Resolution: Rejected
>Priority: 6
Submitted By: Ari Johnson (ari_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-13 02:10

Message:
Logged In: YES 
user_id=90811

A documentation bug...my favorite kind.  Of course, you 
could always do the more malevolent fix, which would 
be to have XML_GetBuffer() return 0xd00d and 
XML_ParseBuffer() return error with message 'you 
blithering idiot, you can't do that!'.  Of course, 
XML_Parse() would not be changed at all, so people who 
use it would automatically get the core dump for 
accessing memory at 0xd00d.

Then again, that probably only works for my users.  
Some people aren't so tolerant. ;)

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-13 01:09

Message:
Logged In: YES 
user_id=290026

Great!
I think you are right - we should add a note to those
functions about when *not* to call them.

I leave this bug report open, so that we don't forget.
I am sure once Fred gets annoyed by the open bug
report he will read this note. <g>

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-13 01:03

Message:
Logged In: YES 
user_id=90811

That worked, thanks!  Maybe you should make a very 
blatant note of that in the reference for all of 
XML_GetBuffer(), XML_ParseBuffer(), and XML_Parse(), as 
well as any other functions that have that requirement.  
Thanks again for the help, and the great library.  It's 
saving me from the bloat. ;)

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-13 00:19

Message:
Logged In: YES 
user_id=290026

Without running your code, just by looking at it:

You are not supposed to call XML_GetBuffer or 
XML_ParseBuffer from within a handler 
(xml_handle_endelement in your case).

Take it out and then try again.
I have a suspicion that that might help.

Karl



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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:39

Message:
Logged In: YES 
user_id=90811

No, my file size is not a multiple of 1024.  Also, as my 
file's name implies and you probably guessed from the 
jabber.xml file I'm using for testing, I intend to use this 
code over a network to communicate with a Jabber 
server.  So I absolutely can't predict my file size in 
advance.  However, I see the oversight you're pointing 
out and will correct it; that's not where this bug is 
coming from, though.

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:34

Message:
Logged In: YES 
user_id=90811

Forgot about my platform-specific code...in test.c, 
change 'stdin->_file' to '0' and 'stdout->_file' to '1'.  
And to run it, ./test < jabber.xml > output.xml


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 17:31

Message:
Logged In: YES 
user_id=290026

Another thought:

If your file size is a multiple of 1024, your code will
call XML_ParseBuffer twice with a buffer size of zero.

This is probably not what is was intended for.
If your file size happens to be like that, maybe you
could try another approach?

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:28

Message:
Logged In: YES 
user_id=90811

I've narrowed the problem down considerably...

I had XML_ParseBuffer() print out 'start' to stderr after it 
sets start in the first bit of the function.  What I found is 
that the contents are correct, for example if I set my 
buffer to equal "<!-- this is a comment -->", then that 
string gets appended to the end of the buffer where it 
should be.  However, start still points to the beginning 
of the previous segment of the buffered text.  This is 
only apparently happening on the call to 
XML_ParseBuffer() after the call that doesn't use the full 
size of the buffer.

Attached, please find a .tar.gz (warning, no directory 
structure, but only 4 files so it shouldn't cause a mess 
for you) with the actual code I'm using.  You'll have to 
compile test.c and xmlstream.c manually and then link 
them to form an executable.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 17:15

Message:
Logged In: YES 
user_id=290026

Since I cannot duplicate this, do you have access
to another platform/OS and can you try it there?
Maybe it is related to the fact that you are compiling
and running this on your version of FreeBSD.



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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:04

Message:
Logged In: YES 
user_id=90811

It doesn't matter what size buffer I request, the 
XML_ParseBuffer() call ends up re-parsing the previous 
buffer when I give it a zero size argument.  Also, even if 
I feed it a fictitious XML comment, it still gives me the 
error 9 - junk after document element.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 16:37

Message:
Logged In: YES 
user_id=290026

Try removing the call for getting a zero sized buffer:
  char *buff = XML_GetBuffer(p, 0);
or change the size parameter back to 1024.
Does that have any effect?


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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:29

Message:
Logged In: YES 
user_id=90811

Just an update...the same thing happens when I don't 
set isFinal in the error-producing call, or of course if I 
feed it more text (since this is just after the </root> tag 
has been read).

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:10

Message:
Logged In: YES 
user_id=90811

I apologize for a mistake; the error it returns is 9 -> 
junk after document element.  I was calling 
GetErrorCode wrong.  Anyhow...

---
int c = 1024;
while(c == 1024) {
  char *buff = XML_GetBuffer(p, 1024);
  if(!buff)
    ...
  c = read(fd, buff, 1024);
  if(c < 0)
    ...
  if(!XML_ParseBuffer(p, c, 0))
    ...
}

...

void handle_end_element(...) {
  if([it was the root element]) {
    char *buff = XML_GetBuffer(p, 0);
    if(!XML_ParseBuffer(p, 0, 1))
      /* This is where the error occurs. */
  }
}


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 15:42

Message:
Logged In: YES 
user_id=290026

In that case please post a small example that can
produce the behaviour you have reported.

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:22

Message:
Logged In: YES 
user_id=90811

Same thing occurs with the current CVS.  This even 
occurs when I actually send XML_Parse*() some text to 
process.  And to make things worse, XML_Parse() 
returns false since it's trying to parse text past the close 
tag of my root element, but the error code is set to 0.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 09:07

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

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


From yolanda1681y81@personales.com  Wed Jul 17 22:07:05 2002
From: yolanda1681y81@personales.com (yolanda1681y81@personales.com)
Date: Wed Jul 17 21:07:05 2002
Subject: For the first time ever                                              
Message-ID: <018a07d64a1c$6723e8b8$7da32ae3@canomp>

---------------------- multipart/mixed attachment

DQpBbiBFYXN5IDMwLTUwJSBSZXR1cm4hDQphbmQgaGVyZSdzIGhvdy4uLi4u
DQoNCkxlYXJuIGhvdyBZT1UgY2FuIHJlY2VpdmUgYSBtb250aGx5IGNoZWNr
DQpmb3IgMywgNCwgb3IgNSUgYSBtb250aCB1bnRpbCB5b3VyIGluaXRpYWwg
aW52ZXN0bWVudA0KaXMgcGFpZCBvZmYuLi50aGVuIGEgbW9udGhseSBjaGVj
ayBmb3Igb3ZlciA0JSBhIG1vbnRoDQpmb3IgeWVhcnMgdG8gY29tZSEhIQ0K
DQpXZSBrbm93IGl0IHNvdW5kcyBpbXBvc3NpYmxlLCBidXQgaXQncyBoYXBw
ZW5pbmcNCnRvZGF5IGFuZCBoZXJlJ3Mgd2hlcmUuDQoNCkluIHRoZSBtZXJj
aGFudCBidXNpbmVzcyEuLi5XaGF0J3MgdGhhdD8/ICANCllvdSBrbm93IHRo
b3NlIGxpdHRsZSBibGFjayBib3hlcyB3aGVyZSBidXNpbmVzc2VzIHN3aXBl
DQp5b3VyIGNyZWRpdCBjYXJkcyEgIFRoYXQncyBjYWxsZWQgUC5PLlMuICAN
ClBvaW50IG9mIFNhbGUgVGVjaG5vbG9neSEgQW5kLCB0aGVzZSBudW1iZXJz
IGFyZSB2ZXJpZmlhYmxlLg0KDQpUaGlzIG11bHRpLXRyaWxsaW9uIGRvbGxh
ciBpbmR1c3RyeSBpbiB3aGljaCBvdXIgYnVzaW5lc3MNCndpbGwgc3VwcGx5
IGNlZGl0IGNhcmRzLCBkZWJpdCBjYXJkcywgY2hlY2sgdmVyaWZpY2F0aW9u
LA0KZnVuZHMgdHJhbnNmZXIsIHByZXBhaWQgY2VsbCBwaG9uZSwgcHJlcGFp
ZCBwaG9uZSBjYXJkcywNCmJpbGwgcGF5bWVudCBhbmQgbWFueSBvdGhlciBz
ZXJ2aWNlcyBmb3IgdGhlIGNvbnN1bWVyIGluDQp0aGUgcmV0YWlsIGVudmly
b25tZW50IHdpdGggcGxlbnR5IG9mIGdyb3d0aCBhaGVhZC4NCg0KU3VjY2Vz
cyBQLk8uUy4gd2lsbCBwcm9mZXNzaW9uYWxseSBtYW5hZ2UgYW5kIHNlcnZp
Y2UNCnlvdXIgYnVzaW5lc3MgZGFpbHkuICBFc3RhYmxpc2hlZCBhbmQgcHJv
dmVuIGxvY2F0aW9ucw0KYXZhaWxhYmxlIG5hdGlvbndpZGUuDQoNClRvIGZp
bmQgb3V0IGhvdyB5b3UgY2FuIHBhcnRpY2lwYXRlIGFuZCBhY2hpZXZlIGEg
bW9udGhseQ0KaW5jb21lIG9mIGJldHdlZW4gMyUgYW5kIDUlICgzMCUgdG8g
NTAlIHllYXJseSkgd2l0aCBhDQpyZWxhdGl2ZWx5IHNtYWxsIGludmVzdG1l
bnQgY29udGFjdCB1cyBub3c6ICANCmh0dHA6Ly93d3cuZW5lcmd5LXBhZ2Uu
Y29tL1BvaW50X29mX1NhbGUNCg0KDQoqKioqKioqKioqT1BULU9VVCBJbnN0
cnVjdGlvbnMqKioqKioqKioqDQpUaGlzIGVtYWlsIGhhcyBiZWVuIHNjcmVl
bmVkIGFuZCBmaWx0ZXJlZCBieSBvdXIgaW4gaG91c2UNCiJPcHQtT3V0IiBz
eXN0ZW0gaW4gY29tcGxpYW5jZSB3aXRoIHN0YXRlIGxhd3MuIElmIHlvdSB3
aXNoIHRvDQpoYXZlIHlvdXIgZW1haWwgYWRkcmVzcyBkZWxldGVkIGZyb20g
dGhpcyBtYWlsaW5nIGFzIHdlbGwgYXMgYW55DQpmdXR1cmUgbWFpbGluZ3Ms
IHBsZWFzZSBnbyB0byBvdXIgIm9wdC1PdXQiIHdlYnNpdGUgYXQ6DQpodHRw
Oi8vd3d3LmVuZXJneS1wYWdlLmNvbS90YWtlbWVvZmYNCg0KODUwNFVrdmU3
LTgzNGZoWlQ1MDQ3d0R4TjctNDIxcmNyaTk2OTJVa2tSMS1sNDENCjE0Mzlx
RFFkMi05MzFGUWwxNA==



---------------------- multipart/mixed attachment--From noreply@sourceforge.net  Wed Jul 17 22:41:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed Jul 17 21:41:01 2002
Subject: [ expat-Bugs-583114 ] 1.95.4 not backward compatible w 1.95.2
Message-ID: <E17V35B-00020t-00@usw-sf-web2.sourceforge.net>

Bugs item #583114, was opened at 2002-07-17 18:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=583114&group_id=10127

Category: None
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Michel Rodriguez (mirod)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.95.4 not backward compatible w 1.95.2

Initial Comment:
When upgrading from 1.95.2 to 1.95.4 I found that the
behaviour of the library has changed: I can no longer
use a fake (non-existent) DTD to avoid entity
declaration errors.

I found the change using XML::Parser but I would think
it is caused by expat (it happened right after I
upgraded it):

perl -MXML::Parser -e'XML::Parser->new->parse( q{<?xml
version="1.0" standalone="no"?><!DOCTYPE doc SYSTEM
"dummy.dtd">
<doc>
  <elt1>toto &ent1;</elt1>
</doc>});'

gives no error using 1.95.2 but a "undefined entity at
line 3, column 13, byte 90" with 1.95.4

I know that trick is devious and certainly slightly
evil, but I found it quite useful ;--)

The new result might be the proper behaviour but it is
not documented (as far as I could tell) and it
certainly breaks compatibility


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-18 00:40

Message:
Logged In: YES 
user_id=290026

Just like my mother. :-)))

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-17 22:46

Message:
Logged In: YES 
user_id=3066

Rejected reports should be closed.

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

Comment By: Michel Rodriguez (mirod)
Date: 2002-07-17 20:41

Message:
Logged In: YES 
user_id=72556

You are right xmlwf  reports an error with this document (I
was using an old version, !@#$%^&* path!)

So my trick does not work any more, too bad, it was quite
convenient. As I use XML::Parser as a base for an other
module (XML::Twig) I can't really control which version of
expat users of the module have installed, so I will just
upgrade the tests (which fail wih 1.95.4), and I might add
an option to use an external entity parser and try to
by-pass the check.

Thanks a lot


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-17 20:05

Message:
Logged In: YES 
user_id=290026

Michel,

At closer inspection, this document is not well-formed,
because Expat detects that it actually has no DTD,
assuming that you didn't set an external entity ref handler.

Once there is no DTD, then standalone="no" doesn't matter
anymore, the spec requires &ent1; to be declared.

However, if you set an external entity handler and pass an
empty file to it, then it might work as it did for you before.
The crucial point would be that you need to create an
external entity parser and call it's XML_Parse function,
if I remember correctly.

In any case, on my system here, Expat reports an
undefined entity error.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-17 19:46

Message:
Logged In: YES 
user_id=290026

Michel,

This change of behaviour is due to a bug fix.
Documentation for fixes can be found in the
associated bug and patch reports.

As a matter of fact, this specific fix is even mentioned
in the release notes for 1.95.4: 
Re-implemented WFC: Entity Declared from XML 1.0 spec ...

I am are aware that fixing bugs may introduce 
incompatibilities, but given the alternative of not fixing them ...

Anyway, if this is crucial to you, I recommend you do
not upgrade.

Karl

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

Comment By: Michel Rodriguez (mirod)
Date: 2002-07-17 19:38

Message:
Logged In: YES 
user_id=72556

I think the bug is actually not due to the library but to
XML::Parser, or at least to XML::Parser's integration with
the library. xmlfw correctly reports that the document is OK
if standalone is set to "no", even with 1.95.4

I will have a look at XML::Parser::Expat but my C is really
rusty :--( 

Thanks

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

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


From noreply@sourceforge.net  Fri Jul 19 15:55:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 19 14:55:02 2002
Subject: [ expat-Patches-584041 ] expat should check XML version attribute
Message-ID: <E17VfhS-0003Ls-00@usw-sf-web5.sourceforge.net>

Patches item #584041, was opened at 2002-07-19 23:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=584041&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Håkan Waara (hwaara)
Assigned to: Nobody/Anonymous (nobody)
Summary: expat should check XML version attribute

Initial Comment:
In the XML spec it says that the parser may throw a 
parser error if the version is not "1.0" in the XML 
declaration. This is also what IE6 does.

Here's a patch for this. It was diffed against mozilla.org's 
expat version, but I hope it can still be applied.

Thanks,  -Håkan

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

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


From noreply@sourceforge.net  Sat Jul 20 06:29:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat Jul 20 05:29:02 2002
Subject: [ expat-Bugs-584183 ] crash in builds without DTD support
Message-ID: <E17VtLn-0007wQ-00@usw-sf-web5.sourceforge.net>

Bugs item #584183, was opened at 2002-07-20 16:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584183&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Matsnev (haali)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash in builds without DTD support

Initial Comment:
expat 1.95.4 crashes when built without dtd support.
The crash occurs when creating the parser in setContext
function. The call to lookup() there tries to access the
dtd.generalEntities table, which is not initialized when
the parser is built without dtd support. The dtdInit
function is not called when XML_DTD is not defined.
dtdInit was always called in 1.95.2 from
XML_ParserCreateMM(), but in 1.95.4 the call was moved
to parserInit(), and conditioned out when building
with XML_DTD undefined.

The attached patch fixes the issue.


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

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


From noreply@sourceforge.net  Sat Jul 20 07:23:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat Jul 20 06:23:04 2002
Subject: [ expat-Patches-584041 ] expat should check XML version attribute
Message-ID: <E17VuBj-0006zV-00@usw-sf-web3.sourceforge.net>

Patches item #584041, was opened at 2002-07-19 17:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=584041&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Håkan Waara (hwaara)
Assigned to: Nobody/Anonymous (nobody)
Summary: expat should check XML version attribute

Initial Comment:
In the XML spec it says that the parser may throw a 
parser error if the version is not "1.0" in the XML 
declaration. This is also what IE6 does.

Here's a patch for this. It was diffed against mozilla.org's 
expat version, but I hope it can still be applied.

Thanks,  -Håkan

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 09:22

Message:
Logged In: YES 
user_id=290026

There is no patch attached.

Karl

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

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


From noreply@sourceforge.net  Sat Jul 20 07:34:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat Jul 20 06:34:02 2002
Subject: [ expat-Bugs-584183 ] crash in builds without DTD support
Message-ID: <E17VuML-0005on-00@usw-sf-web1.sourceforge.net>

Bugs item #584183, was opened at 2002-07-20 08:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584183&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Matsnev (haali)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash in builds without DTD support

Initial Comment:
expat 1.95.4 crashes when built without dtd support.
The crash occurs when creating the parser in setContext
function. The call to lookup() there tries to access the
dtd.generalEntities table, which is not initialized when
the parser is built without dtd support. The dtdInit
function is not called when XML_DTD is not defined.
dtdInit was always called in 1.95.2 from
XML_ParserCreateMM(), but in 1.95.4 the call was moved
to parserInit(), and conditioned out when building
with XML_DTD undefined.

The attached patch fixes the issue.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 09:33

Message:
Logged In: YES 
user_id=290026

Thanks for finding the bug.
I already applied your patch to CVS.

Expat witout XML_DTD defined is not tested well,
since that option is not widely used.

I would appreciate it if you kept testing it.

Karl

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

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


From noreply@sourceforge.net  Sat Jul 20 07:35:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat Jul 20 06:35:02 2002
Subject: [ expat-Bugs-584183 ] crash in builds without DTD support
Message-ID: <E17VuNJ-0005pu-00@usw-sf-web1.sourceforge.net>

Bugs item #584183, was opened at 2002-07-20 08:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584183&group_id=10127

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Mike Matsnev (haali)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash in builds without DTD support

Initial Comment:
expat 1.95.4 crashes when built without dtd support.
The crash occurs when creating the parser in setContext
function. The call to lookup() there tries to access the
dtd.generalEntities table, which is not initialized when
the parser is built without dtd support. The dtdInit
function is not called when XML_DTD is not defined.
dtdInit was always called in 1.95.2 from
XML_ParserCreateMM(), but in 1.95.4 the call was moved
to parserInit(), and conditioned out when building
with XML_DTD undefined.

The attached patch fixes the issue.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 09:34

Message:
Logged In: YES 
user_id=290026

Closed, since patch was accepted and applied.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 09:33

Message:
Logged In: YES 
user_id=290026

Thanks for finding the bug.
I already applied your patch to CVS.

Expat witout XML_DTD defined is not tested well,
since that option is not widely used.

I would appreciate it if you kept testing it.

Karl

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

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


From noreply@sourceforge.net  Sat Jul 20 08:22:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat Jul 20 07:22:03 2002
Subject: [ expat-Patches-584041 ] expat should check XML version attribute
Message-ID: <E17Vv6Y-0003ox-00@usw-sf-web4.sourceforge.net>

Patches item #584041, was opened at 2002-07-19 23:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=584041&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Håkan Waara (hwaara)
Assigned to: Nobody/Anonymous (nobody)
Summary: expat should check XML version attribute

Initial Comment:
In the XML spec it says that the parser may throw a 
parser error if the version is not "1.0" in the XML 
declaration. This is also what IE6 does.

Here's a patch for this. It was diffed against mozilla.org's 
expat version, but I hope it can still be applied.

Thanks,  -Håkan

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

>Comment By: Håkan Waara (hwaara)
Date: 2002-07-20 16:21

Message:
Logged In: YES 
user_id=72743

Ok, now the patch is uploaded.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 15:22

Message:
Logged In: YES 
user_id=290026

There is no patch attached.

Karl

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

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


From noreply@sourceforge.net  Sat Jul 20 09:36:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat Jul 20 08:36:02 2002
Subject: [ expat-Patches-584041 ] expat should check XML version attribute
Message-ID: <E17VwGI-00053t-00@usw-sf-web4.sourceforge.net>

Patches item #584041, was opened at 2002-07-19 17:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=584041&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Håkan Waara (hwaara)
Assigned to: Nobody/Anonymous (nobody)
Summary: expat should check XML version attribute

Initial Comment:
In the XML spec it says that the parser may throw a 
parser error if the version is not "1.0" in the XML 
declaration. This is also what IE6 does.

Here's a patch for this. It was diffed against mozilla.org's 
expat version, but I hope it can still be applied.

Thanks,  -Håkan

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 11:35

Message:
Logged In: YES 
user_id=290026

Thanks for the upload.

Now, the question is: Since it is not a requirement to
throw an error, but just optional behaviour, is there
a compelling reason to add this to Expat?

Karl

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

Comment By: Håkan Waara (hwaara)
Date: 2002-07-20 10:21

Message:
Logged In: YES 
user_id=72743

Ok, now the patch is uploaded.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 09:22

Message:
Logged In: YES 
user_id=290026

There is no patch attached.

Karl

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

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


From noreply@sourceforge.net  Sat Jul 20 09:40:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat Jul 20 08:40:02 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17VwJu-0006j0-00@usw-sf-web2.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 05:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: Documentation
Group: None
Status: Open
Resolution: Rejected
Priority: 6
Submitted By: Ari Johnson (ari_j)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 11:38

Message:
Logged In: YES 
user_id=290026

Fred once indicated that documentation is one of his
interests. Anticipating that he is very eager to take care
of this issue, I am assigning it to him . <bg>

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-13 02:10

Message:
Logged In: YES 
user_id=90811

A documentation bug...my favorite kind.  Of course, you 
could always do the more malevolent fix, which would 
be to have XML_GetBuffer() return 0xd00d and 
XML_ParseBuffer() return error with message 'you 
blithering idiot, you can't do that!'.  Of course, 
XML_Parse() would not be changed at all, so people who 
use it would automatically get the core dump for 
accessing memory at 0xd00d.

Then again, that probably only works for my users.  
Some people aren't so tolerant. ;)

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-13 01:09

Message:
Logged In: YES 
user_id=290026

Great!
I think you are right - we should add a note to those
functions about when *not* to call them.

I leave this bug report open, so that we don't forget.
I am sure once Fred gets annoyed by the open bug
report he will read this note. <g>

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-13 01:03

Message:
Logged In: YES 
user_id=90811

That worked, thanks!  Maybe you should make a very 
blatant note of that in the reference for all of 
XML_GetBuffer(), XML_ParseBuffer(), and XML_Parse(), as 
well as any other functions that have that requirement.  
Thanks again for the help, and the great library.  It's 
saving me from the bloat. ;)

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-13 00:19

Message:
Logged In: YES 
user_id=290026

Without running your code, just by looking at it:

You are not supposed to call XML_GetBuffer or 
XML_ParseBuffer from within a handler 
(xml_handle_endelement in your case).

Take it out and then try again.
I have a suspicion that that might help.

Karl



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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:39

Message:
Logged In: YES 
user_id=90811

No, my file size is not a multiple of 1024.  Also, as my 
file's name implies and you probably guessed from the 
jabber.xml file I'm using for testing, I intend to use this 
code over a network to communicate with a Jabber 
server.  So I absolutely can't predict my file size in 
advance.  However, I see the oversight you're pointing 
out and will correct it; that's not where this bug is 
coming from, though.

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:34

Message:
Logged In: YES 
user_id=90811

Forgot about my platform-specific code...in test.c, 
change 'stdin->_file' to '0' and 'stdout->_file' to '1'.  
And to run it, ./test < jabber.xml > output.xml


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 17:31

Message:
Logged In: YES 
user_id=290026

Another thought:

If your file size is a multiple of 1024, your code will
call XML_ParseBuffer twice with a buffer size of zero.

This is probably not what is was intended for.
If your file size happens to be like that, maybe you
could try another approach?

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:28

Message:
Logged In: YES 
user_id=90811

I've narrowed the problem down considerably...

I had XML_ParseBuffer() print out 'start' to stderr after it 
sets start in the first bit of the function.  What I found is 
that the contents are correct, for example if I set my 
buffer to equal "<!-- this is a comment -->", then that 
string gets appended to the end of the buffer where it 
should be.  However, start still points to the beginning 
of the previous segment of the buffered text.  This is 
only apparently happening on the call to 
XML_ParseBuffer() after the call that doesn't use the full 
size of the buffer.

Attached, please find a .tar.gz (warning, no directory 
structure, but only 4 files so it shouldn't cause a mess 
for you) with the actual code I'm using.  You'll have to 
compile test.c and xmlstream.c manually and then link 
them to form an executable.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 17:15

Message:
Logged In: YES 
user_id=290026

Since I cannot duplicate this, do you have access
to another platform/OS and can you try it there?
Maybe it is related to the fact that you are compiling
and running this on your version of FreeBSD.



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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:04

Message:
Logged In: YES 
user_id=90811

It doesn't matter what size buffer I request, the 
XML_ParseBuffer() call ends up re-parsing the previous 
buffer when I give it a zero size argument.  Also, even if 
I feed it a fictitious XML comment, it still gives me the 
error 9 - junk after document element.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 16:37

Message:
Logged In: YES 
user_id=290026

Try removing the call for getting a zero sized buffer:
  char *buff = XML_GetBuffer(p, 0);
or change the size parameter back to 1024.
Does that have any effect?


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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:29

Message:
Logged In: YES 
user_id=90811

Just an update...the same thing happens when I don't 
set isFinal in the error-producing call, or of course if I 
feed it more text (since this is just after the </root> tag 
has been read).

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:10

Message:
Logged In: YES 
user_id=90811

I apologize for a mistake; the error it returns is 9 -> 
junk after document element.  I was calling 
GetErrorCode wrong.  Anyhow...

---
int c = 1024;
while(c == 1024) {
  char *buff = XML_GetBuffer(p, 1024);
  if(!buff)
    ...
  c = read(fd, buff, 1024);
  if(c < 0)
    ...
  if(!XML_ParseBuffer(p, c, 0))
    ...
}

...

void handle_end_element(...) {
  if([it was the root element]) {
    char *buff = XML_GetBuffer(p, 0);
    if(!XML_ParseBuffer(p, 0, 1))
      /* This is where the error occurs. */
  }
}


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 15:42

Message:
Logged In: YES 
user_id=290026

In that case please post a small example that can
produce the behaviour you have reported.

Karl

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

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:22

Message:
Logged In: YES 
user_id=90811

Same thing occurs with the current CVS.  This even 
occurs when I actually send XML_Parse*() some text to 
process.  And to make things worse, XML_Parse() 
returns false since it's trying to parse text past the close 
tag of my root element, but the error code is set to 0.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 09:07

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

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

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


From noreply@sourceforge.net  Sat Jul 20 09:52:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat Jul 20 08:52:03 2002
Subject: [ expat-Patches-584041 ] expat should check XML version attribute
Message-ID: <E17VwWR-0005Po-00@usw-sf-web4.sourceforge.net>

Patches item #584041, was opened at 2002-07-19 23:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=584041&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Håkan Waara (hwaara)
Assigned to: Nobody/Anonymous (nobody)
Summary: expat should check XML version attribute

Initial Comment:
In the XML spec it says that the parser may throw a 
parser error if the version is not "1.0" in the XML 
declaration. This is also what IE6 does.

Here's a patch for this. It was diffed against mozilla.org's 
expat version, but I hope it can still be applied.

Thanks,  -Håkan

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

>Comment By: Håkan Waara (hwaara)
Date: 2002-07-20 17:51

Message:
Logged In: YES 
user_id=72743

From noreply@sourceforge.net  Sat Jul 20 10:00:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat Jul 20 09:00:03 2002
Subject: [ expat-Patches-584041 ] expat should check XML version attribute
Message-ID: <E17Vwdr-0008Av-00@usw-sf-web1.sourceforge.net>

Patches item #584041, was opened at 2002-07-19 17:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=584041&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Håkan Waara (hwaara)
Assigned to: Nobody/Anonymous (nobody)
Summary: expat should check XML version attribute

Initial Comment:
In the XML spec it says that the parser may throw a 
parser error if the version is not "1.0" in the XML 
declaration. This is also what IE6 does.

Here's a patch for this. It was diffed against mozilla.org's 
expat version, but I hope it can still be applied.

Thanks,  -Håkan

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 11:59

Message:
Logged In: YES 
user_id=290026

Yes, I have read the spec too.
I also read about the XML 1.1 spec making it a requirement.

I am just putting it up for discussion.
Why don't you post to the expat-discuss list?

Karl

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

Comment By: Håkan Waara (hwaara)
Date: 2002-07-20 11:51

Message:
Logged In: YES 
user_id=72743

From marylou4247g67@skomakergata.com  Sat Jul 20 15:02:02 2002
From: marylou4247g67@skomakergata.com (marylou4247g67@skomakergata.com)
Date: Sat Jul 20 14:02:02 2002
Subject: *Toss The 9 to 5*                                                                      2127OOwx4-179pmSf8730YMFz0-282-28
Message-ID: <033e47d55d1e$5327a6d6$3ac44ee3@ydxghn>

An Easy 30-50% Return!
and here's how.....

Learn how YOU can receive a monthly check
for 3, 4, or 5% a month until your initial investment
is paid off...then a monthly check for over 4% a month
for years to come!!!

We know it sounds impossible, but it's happening
today and here's where.

In the merchant business!...What's that??  
You know those little black boxes where businesses swipe
your credit cards!  That's called P.O.S.  
Point of Sale Technology! And, these numbers are verifiable.

This multi-trillion dollar industry in which our business
will supply cedit cards, debit cards, check verification,
funds transfer, prepaid cell phone, prepaid phone cards,
bill payment and many other services for the consumer in
the retail environment with plenty of growth ahead.

Success P.O.S. will professionally manage and service
your business daily.  Established and proven locations
available nationwide.

To find out how you can participate and achieve a monthly
income of between 3% and 5% (30% to 50% yearly) with a
relatively small investment contact us now:  
http://209.163.187.49/poseg


**********OPT-OUT Instructions**********
This email has been screened and filtered by our in house
"Opt-Out" system in compliance with state laws. If you wish to
have your email address deleted from this mailing as well as any
future mailings, please go to our "opt-Out" website at:
http://209.163.187.49/poseg/optout.html

6939kFIb2-631WHZB6090kdJA1-048MeVb3402uUJM8-728YSGw4510qWNf1-764zEre96l66
8417zTEG9-616LZkS0320ChdP9-028KwgU5819ziLf3-036wRIT61l50


From noreply@sourceforge.net  Sat Jul 20 19:59:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat Jul 20 18:59:02 2002
Subject: [ expat-Patches-584041 ] expat should check XML version attribute
Message-ID: <E17W5zY-0003oe-00@usw-sf-web5.sourceforge.net>

Patches item #584041, was opened at 2002-07-19 17:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=584041&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Håkan Waara (hwaara)
>Assigned to: Karl Waclawek (kwaclaw)
Summary: expat should check XML version attribute

Initial Comment:
In the XML spec it says that the parser may throw a 
parser error if the version is not "1.0" in the XML 
declaration. This is also what IE6 does.

Here's a patch for this. It was diffed against mozilla.org's 
expat version, but I hope it can still be applied.

Thanks,  -Håkan

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 21:58

Message:
Logged In: YES 
user_id=290026

The patch didn't work for me, but I applied it manually
against my copy of the current CVS (xmltok.c 1.20) 
- with small cosmetic changes.

Attached as xmltok.diff.

I am in favour of it. Let's see what the others say.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 11:59

Message:
Logged In: YES 
user_id=290026

Yes, I have read the spec too.
I also read about the XML 1.1 spec making it a requirement.

I am just putting it up for discussion.
Why don't you post to the expat-discuss list?

Karl

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

Comment By: Håkan Waara (hwaara)
Date: 2002-07-20 11:51

Message:
Logged In: YES 
user_id=72743

From tamiko2713c88@philippines.to  Sun Jul 21 01:27:04 2002
From: tamiko2713c88@philippines.to (tamiko2713c88@philippines.to)
Date: Sun Jul 21 00:27:04 2002
Subject: Job security Easy 30-50%                                 3317ShdX3-337tcYg-16
Message-ID: <037a64e80e1b$4638e6a2$5ab85ae1@ftdtne>

An Easy 30-50% Return!
and here's how.....

Learn how YOU can receive a monthly check
for 3, 4, or 5% a month until your initial investment
is paid off...then a monthly check for over 4% a month
for years to come!!!

We know it sounds impossible, but it's happening
today and here's where.

In the merchant business!...What's that??  
You know those little black boxes where businesses swipe
your credit cards!  That's called P.O.S.  
Point of Sale Technology! And, these numbers are verifiable.

This multi-trillion dollar industry in which our business
will supply cedit cards, debit cards, check verification,
funds transfer, prepaid cell phone, prepaid phone cards,
bill payment and many other services for the consumer in
the retail environment with plenty of growth ahead.

Success P.O.S. will professionally manage and service
your business daily.  Established and proven locations
available nationwide.

To find out how you can participate and achieve a monthly
income of between 3% and 5% (30% to 50% yearly) with a
relatively small investment contact us now:  
http://209.163.187.49/poseg



**********OPT-OUT Instructions**********
This email has been screened and filtered by our in house
"Opt-Out" system in compliance with state laws. If you wish to
have your email address deleted from this mailing as well as any
future mailings, please go to our "opt-Out" website at:
http://209.163.187.49/poseg/optout.html


6370bbPK8-468uyth4466MlVH3-405bzXQ5238YumA5-9l42
0505AUMp2-120GsQN1133Mmgv9-150OZVq7221IOTl39


From noreply@sourceforge.net  Sun Jul 21 07:43:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun Jul 21 06:43:03 2002
Subject: [ expat-Bugs-584483 ] Add expat.h to Windows install
Message-ID: <E17WGyP-0001um-00@usw-sf-web3.sourceforge.net>

Bugs item #584483, was opened at 2002-07-21 06:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584483&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: Add expat.h to Windows install

Initial Comment:
Would it be possible to add expat.h to the Windows binary 
install. This header file is public heder file needed to build 
other libraries, and it would be nice to have it in binary 
distribution (together with libraries). Otherwise source 
distribution needs to be downloaded for this one file only.
 

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

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


From noreply@sourceforge.net  Mon Jul 22 04:29:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul 22 03:29:04 2002
Subject: [ expat-Bugs-584832 ] incorrect handling of internal entities
Message-ID: <E17WaQr-00077Q-00@usw-sf-web4.sourceforge.net>

Bugs item #584832, was opened at 2002-07-22 14:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584832&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Matsnev (haali)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect handling of internal entities

Initial Comment:
expat-1.95.4

Internal entities defined in the DTD are not properly
expanded in attribute values when an external encoding
handler is used. 

The cause of the problem is that a wrong pool is
cleared in processXmlDecl() and the encoding name
remains in the pool. When parsing the document an
entity name is appended to the encoding name already in
the pool, and not surprisingly the resulting string is
not found in the entities table. The attached patch
fixes the bug.

Also this bug might cause trouble in other places,
where the temp2pool is used.

/Mike

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

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


From noreply@sourceforge.net  Mon Jul 22 07:31:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul 22 06:31:09 2002
Subject: [ expat-Bugs-584832 ] incorrect handling of internal entities
Message-ID: <E17WdGI-0007Le-00@usw-sf-web3.sourceforge.net>

Bugs item #584832, was opened at 2002-07-22 06:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584832&group_id=10127

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Mike Matsnev (haali)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect handling of internal entities

Initial Comment:
expat-1.95.4

Internal entities defined in the DTD are not properly
expanded in attribute values when an external encoding
handler is used. 

The cause of the problem is that a wrong pool is
cleared in processXmlDecl() and the encoding name
remains in the pool. When parsing the document an
entity name is appended to the encoding name already in
the pool, and not surprisingly the resulting string is
not found in the entities table. The attached patch
fixes the bug.

Also this bug might cause trouble in other places,
where the temp2pool is used.

/Mike

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 09:30

Message:
Logged In: YES 
user_id=290026

I think your assessment is correct. 
Thank you for your bug report.
Could you please supply a test case for that - obviously
you have come across the bug in a specific case.

I already applied the patch. Leaving this report open
until test case (hopefully :-)) supplied.

Karl

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

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


From noreply@sourceforge.net  Mon Jul 22 07:40:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul 22 06:40:08 2002
Subject: [ expat-Bugs-584832 ] incorrect handling of internal entities
Message-ID: <E17WdPX-0007cN-00@usw-sf-web3.sourceforge.net>

Bugs item #584832, was opened at 2002-07-22 06:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584832&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Mike Matsnev (haali)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: incorrect handling of internal entities

Initial Comment:
expat-1.95.4

Internal entities defined in the DTD are not properly
expanded in attribute values when an external encoding
handler is used. 

The cause of the problem is that a wrong pool is
cleared in processXmlDecl() and the encoding name
remains in the pool. When parsing the document an
entity name is appended to the encoding name already in
the pool, and not surprisingly the resulting string is
not found in the entities table. The attached patch
fixes the bug.

Also this bug might cause trouble in other places,
where the temp2pool is used.

/Mike

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 09:39

Message:
Logged In: YES 
user_id=290026

Assigned to Fred - he usually takes care of test cases.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 09:30

Message:
Logged In: YES 
user_id=290026

I think your assessment is correct. 
Thank you for your bug report.
Could you please supply a test case for that - obviously
you have come across the bug in a specific case.

I already applied the patch. Leaving this report open
until test case (hopefully :-)) supplied.

Karl

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

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


From noreply@sourceforge.net  Mon Jul 22 07:44:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul 22 06:44:03 2002
Subject: [ expat-Patches-584041 ] expat should check XML version attribute
Message-ID: <E17WdSt-0008NE-00@usw-sf-web2.sourceforge.net>

Patches item #584041, was opened at 2002-07-19 17:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=584041&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Håkan Waara (hwaara)
Assigned to: Karl Waclawek (kwaclaw)
Summary: expat should check XML version attribute

Initial Comment:
In the XML spec it says that the parser may throw a 
parser error if the version is not "1.0" in the XML 
declaration. This is also what IE6 does.

Here's a patch for this. It was diffed against mozilla.org's 
expat version, but I hope it can still be applied.

Thanks,  -Håkan

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 09:43

Message:
Logged In: YES 
user_id=290026

One caveat though:

What will happen with XML 1.1 documents that
also conform to XML 1.0? Should the parser reject them?
That might potentially exclude many "good" documents.

Maybe an option should be added to turn version
number errors of.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 21:58

Message:
Logged In: YES 
user_id=290026

The patch didn't work for me, but I applied it manually
against my copy of the current CVS (xmltok.c 1.20) 
- with small cosmetic changes.

Attached as xmltok.diff.

I am in favour of it. Let's see what the others say.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 11:59

Message:
Logged In: YES 
user_id=290026

Yes, I have read the spec too.
I also read about the XML 1.1 spec making it a requirement.

I am just putting it up for discussion.
Why don't you post to the expat-discuss list?

Karl

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

Comment By: Håkan Waara (hwaara)
Date: 2002-07-20 11:51

Message:
Logged In: YES 
user_id=72743

From noreply@sourceforge.net  Mon Jul 22 08:04:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul 22 07:04:02 2002
Subject: [ expat-Bugs-584832 ] incorrect handling of internal entities
Message-ID: <E17WdmI-0007V3-00@usw-sf-web5.sourceforge.net>

Bugs item #584832, was opened at 2002-07-22 14:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584832&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Mike Matsnev (haali)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: incorrect handling of internal entities

Initial Comment:
expat-1.95.4

Internal entities defined in the DTD are not properly
expanded in attribute values when an external encoding
handler is used. 

The cause of the problem is that a wrong pool is
cleared in processXmlDecl() and the encoding name
remains in the pool. When parsing the document an
entity name is appended to the encoding name already in
the pool, and not surprisingly the resulting string is
not found in the entities table. The attached patch
fixes the bug.

Also this bug might cause trouble in other places,
where the temp2pool is used.

/Mike

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

>Comment By: Mike Matsnev (haali)
Date: 2002-07-22 18:03

Message:
Logged In: YES 
user_id=287590

I wrote a simple test case that produces the output: "not
ok: undefined entity" before the fix, and "ok" after.

/Mike

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 17:39

Message:
Logged In: YES 
user_id=290026

Assigned to Fred - he usually takes care of test cases.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 17:30

Message:
Logged In: YES 
user_id=290026

I think your assessment is correct. 
Thank you for your bug report.
Could you please supply a test case for that - obviously
you have come across the bug in a specific case.

I already applied the patch. Leaving this report open
until test case (hopefully :-)) supplied.

Karl

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

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


From noreply@sourceforge.net  Mon Jul 22 08:04:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul 22 07:04:05 2002
Subject: [ expat-Bugs-584832 ] incorrect handling of internal entities
Message-ID: <E17WdmP-0007VI-00@usw-sf-web5.sourceforge.net>

Bugs item #584832, was opened at 2002-07-22 14:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584832&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Mike Matsnev (haali)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: incorrect handling of internal entities

Initial Comment:
expat-1.95.4

Internal entities defined in the DTD are not properly
expanded in attribute values when an external encoding
handler is used. 

The cause of the problem is that a wrong pool is
cleared in processXmlDecl() and the encoding name
remains in the pool. When parsing the document an
entity name is appended to the encoding name already in
the pool, and not surprisingly the resulting string is
not found in the entities table. The attached patch
fixes the bug.

Also this bug might cause trouble in other places,
where the temp2pool is used.

/Mike

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

>Comment By: Mike Matsnev (haali)
Date: 2002-07-22 18:03

Message:
Logged In: YES 
user_id=287590

I wrote a simple test case that produces the output: "not
ok: undefined entity" before the fix, and "ok" after.

/Mike

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

Comment By: Mike Matsnev (haali)
Date: 2002-07-22 18:03

Message:
Logged In: YES 
user_id=287590

I wrote a simple test case that produces the output: "not
ok: undefined entity" before the fix, and "ok" after.

/Mike

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 17:39

Message:
Logged In: YES 
user_id=290026

Assigned to Fred - he usually takes care of test cases.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 17:30

Message:
Logged In: YES 
user_id=290026

I think your assessment is correct. 
Thank you for your bug report.
Could you please supply a test case for that - obviously
you have come across the bug in a specific case.

I already applied the patch. Leaving this report open
until test case (hopefully :-)) supplied.

Karl

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

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


From noreply@sourceforge.net  Mon Jul 22 08:08:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul 22 07:08:04 2002
Subject: [ expat-Bugs-584832 ] incorrect handling of internal entities
Message-ID: <E17WdqA-0007b6-00@usw-sf-web5.sourceforge.net>

Bugs item #584832, was opened at 2002-07-22 06:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584832&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Mike Matsnev (haali)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: incorrect handling of internal entities

Initial Comment:
expat-1.95.4

Internal entities defined in the DTD are not properly
expanded in attribute values when an external encoding
handler is used. 

The cause of the problem is that a wrong pool is
cleared in processXmlDecl() and the encoding name
remains in the pool. When parsing the document an
entity name is appended to the encoding name already in
the pool, and not surprisingly the resulting string is
not found in the entities table. The attached patch
fixes the bug.

Also this bug might cause trouble in other places,
where the temp2pool is used.

/Mike

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 10:07

Message:
Logged In: YES 
user_id=290026

Thanks a lot!

Now it's up to you, Fred.

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

Comment By: Mike Matsnev (haali)
Date: 2002-07-22 10:03

Message:
Logged In: YES 
user_id=287590

I wrote a simple test case that produces the output: "not
ok: undefined entity" before the fix, and "ok" after.

/Mike

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

Comment By: Mike Matsnev (haali)
Date: 2002-07-22 10:03

Message:
Logged In: YES 
user_id=287590

I wrote a simple test case that produces the output: "not
ok: undefined entity" before the fix, and "ok" after.

/Mike

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 09:39

Message:
Logged In: YES 
user_id=290026

Assigned to Fred - he usually takes care of test cases.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 09:30

Message:
Logged In: YES 
user_id=290026

I think your assessment is correct. 
Thank you for your bug report.
Could you please supply a test case for that - obviously
you have come across the bug in a specific case.

I already applied the patch. Leaving this report open
until test case (hopefully :-)) supplied.

Karl

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

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


From noreply@sourceforge.net  Mon Jul 22 09:38:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul 22 08:38:10 2002
Subject: [ expat-Bugs-584483 ] Add expat.h to Windows install
Message-ID: <E17WfFk-0004QB-00@usw-sf-web4.sourceforge.net>

Bugs item #584483, was opened at 2002-07-21 09:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584483&group_id=10127

Category: Build control
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: Add expat.h to Windows install

Initial Comment:
Would it be possible to add expat.h to the Windows binary 
install. This header file is public heder file needed to build 
other libraries, and it would be nice to have it in binary 
distribution (together with libraries). Otherwise source 
distribution needs to be downloaded for this one file only.
 

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-22 11:37

Message:
Logged In: YES 
user_id=3066

expat.h is included in the Source\lib\ directory in the
installation.  (Where did you expect to find it?)

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

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


From noreply@sourceforge.net  Mon Jul 22 09:58:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul 22 08:58:03 2002
Subject: [ expat-Patches-584041 ] expat should check XML version attribute
Message-ID: <E17WfYS-0004r5-00@usw-sf-web4.sourceforge.net>

Patches item #584041, was opened at 2002-07-19 17:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=584041&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Håkan Waara (hwaara)
Assigned to: Karl Waclawek (kwaclaw)
Summary: expat should check XML version attribute

Initial Comment:
In the XML spec it says that the parser may throw a 
parser error if the version is not "1.0" in the XML 
declaration. This is also what IE6 does.

Here's a patch for this. It was diffed against mozilla.org's 
expat version, but I hope it can still be applied.

Thanks,  -Håkan

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-22 11:57

Message:
Logged In: YES 
user_id=3066

While I like being really picky about checking input, I
think there's a backward compatibility issue here.  To turn
version != "1.0" into an error, we break with expectations
established by previous releases.  Expat legacy does not
turn conditions into actual errors if it isn't necessary, so
"may" raise an error is not strong enough to go against
existing behavior.

If a particular application is interested in deteriming what
XML version was given, it may do so using
XML_SetXmlDeclHandler(), raising any sort of error
appropriate at that point.  This should be documented
(assign to me for docs once we reach agreement).

XML 1.1 feels sufficiently rough at this point that we don't
need to implement to it.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 09:43

Message:
Logged In: YES 
user_id=290026

One caveat though:

What will happen with XML 1.1 documents that
also conform to XML 1.0? Should the parser reject them?
That might potentially exclude many "good" documents.

Maybe an option should be added to turn version
number errors of.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 21:58

Message:
Logged In: YES 
user_id=290026

The patch didn't work for me, but I applied it manually
against my copy of the current CVS (xmltok.c 1.20) 
- with small cosmetic changes.

Attached as xmltok.diff.

I am in favour of it. Let's see what the others say.

Karl

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 11:59

Message:
Logged In: YES 
user_id=290026

Yes, I have read the spec too.
I also read about the XML 1.1 spec making it a requirement.

I am just putting it up for discussion.
Why don't you post to the expat-discuss list?

Karl

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

Comment By: Håkan Waara (hwaara)
Date: 2002-07-20 11:51

Message:
Logged In: YES 
user_id=72743

From noreply@sourceforge.net  Mon Jul 22 10:30:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul 22 09:30:03 2002
Subject: [ expat-Patches-584041 ] expat should check XML version attribute
Message-ID: <E17Wg3r-0002nH-00@usw-sf-web5.sourceforge.net>

Patches item #584041, was opened at 2002-07-19 17:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=584041&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Håkan Waara (hwaara)
Assigned to: Karl Waclawek (kwaclaw)
Summary: expat should check XML version attribute

Initial Comment:
In the XML spec it says that the parser may throw a 
parser error if the version is not "1.0" in the XML 
declaration. This is also what IE6 does.

Here's a patch for this. It was diffed against mozilla.org's 
expat version, but I hope it can still be applied.

Thanks,  -Håkan

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 12:29

Message:
Logged In: YES 
user_id=290026

I like the idea of leaving it to the application
to make the call: error or not.

Given the other arguments (mine included <g>)
I reverse my vote - I am now in favour of the status quo.

We will see what the experiences with the Mozilla 
version of Expat (where this patch comes from) will be ...

Karl

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-22 11:57

Message:
Logged In: YES 
user_id=3066

While I like being really picky about checking input, I
think there's a backward compatibility issue here.  To turn
version != "1.0" into an error, we break with expectations
established by previous releases.  Expat legacy does not
turn conditions into actual errors if it isn't necessary, so
"may" raise an error is not strong enough to go against
existing behavior.

If a particular application is interested in deteriming what
XML version was given, it may do so using
XML_SetXmlDeclHandler(), raising any sort of error
appropriate at that point.  This should be documented
(assign to me for docs once we reach agreement).

XML 1.1 feels sufficiently rough at this point that we don't
need to implement to it.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 09:43

Message:
Logged In: YES 
user_id=290026

One caveat though:

What will happen with XML 1.1 documents that
also conform to XML 1.0? Should the parser reject them?
That might potentially exclude many "good" documents.

Maybe an option should be added to turn version
number errors of.

Karl

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 21:58

Message:
Logged In: YES 
user_id=290026

The patch didn't work for me, but I applied it manually
against my copy of the current CVS (xmltok.c 1.20) 
- with small cosmetic changes.

Attached as xmltok.diff.

I am in favour of it. Let's see what the others say.

Karl

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 11:59

Message:
Logged In: YES 
user_id=290026

Yes, I have read the spec too.
I also read about the XML 1.1 spec making it a requirement.

I am just putting it up for discussion.
Why don't you post to the expat-discuss list?

Karl

----------------------------------------------------------------------

Comment By: Håkan Waara (hwaara)
Date: 2002-07-20 11:51

Message:
Logged In: YES 
user_id=72743

From noreply@sourceforge.net  Mon Jul 22 10:43:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul 22 09:43:10 2002
Subject: [ expat-Bugs-584041 ] Document handling of XML version
Message-ID: <E17WgG1-0002wB-00@usw-sf-web3.sourceforge.net>

Bugs item #584041, was opened at 2002-07-19 17:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584041&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Håkan Waara (hwaara)
>Assigned to: Nobody/Anonymous (nobody)
>Summary: Document handling of XML version

Initial Comment:
In the XML spec it says that the parser may throw a 
parser error if the version is not "1.0" in the XML 
declaration. This is also what IE6 does.

Here's a patch for this. It was diffed against mozilla.org's 
expat version, but I hope it can still be applied.

Thanks,  -Håkan

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-22 12:42

Message:
Logged In: YES 
user_id=3066

Assigned to me and updated summary to reflect newfound
existence as a request for documentation.  Re-filed into the
"bug" tracker.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 12:29

Message:
Logged In: YES 
user_id=290026

I like the idea of leaving it to the application
to make the call: error or not.

Given the other arguments (mine included <g>)
I reverse my vote - I am now in favour of the status quo.

We will see what the experiences with the Mozilla 
version of Expat (where this patch comes from) will be ...

Karl

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-22 11:57

Message:
Logged In: YES 
user_id=3066

While I like being really picky about checking input, I
think there's a backward compatibility issue here.  To turn
version != "1.0" into an error, we break with expectations
established by previous releases.  Expat legacy does not
turn conditions into actual errors if it isn't necessary, so
"may" raise an error is not strong enough to go against
existing behavior.

If a particular application is interested in deteriming what
XML version was given, it may do so using
XML_SetXmlDeclHandler(), raising any sort of error
appropriate at that point.  This should be documented
(assign to me for docs once we reach agreement).

XML 1.1 feels sufficiently rough at this point that we don't
need to implement to it.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 09:43

Message:
Logged In: YES 
user_id=290026

One caveat though:

What will happen with XML 1.1 documents that
also conform to XML 1.0? Should the parser reject them?
That might potentially exclude many "good" documents.

Maybe an option should be added to turn version
number errors of.

Karl

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 21:58

Message:
Logged In: YES 
user_id=290026

The patch didn't work for me, but I applied it manually
against my copy of the current CVS (xmltok.c 1.20) 
- with small cosmetic changes.

Attached as xmltok.diff.

I am in favour of it. Let's see what the others say.

Karl

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 11:59

Message:
Logged In: YES 
user_id=290026

Yes, I have read the spec too.
I also read about the XML 1.1 spec making it a requirement.

I am just putting it up for discussion.
Why don't you post to the expat-discuss list?

Karl

----------------------------------------------------------------------

Comment By: Håkan Waara (hwaara)
Date: 2002-07-20 11:51

Message:
Logged In: YES 
user_id=72743

From noreply@sourceforge.net  Mon Jul 22 10:50:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul 22 09:50:03 2002
Subject: [ expat-Bugs-584832 ] incorrect handling of internal entities
Message-ID: <E17WgNP-0003EM-00@usw-sf-web5.sourceforge.net>

Bugs item #584832, was opened at 2002-07-22 06:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584832&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Accepted
>Priority: 6
Submitted By: Mike Matsnev (haali)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: incorrect handling of internal entities

Initial Comment:
expat-1.95.4

Internal entities defined in the DTD are not properly
expanded in attribute values when an external encoding
handler is used. 

The cause of the problem is that a wrong pool is
cleared in processXmlDecl() and the encoding name
remains in the pool. When parsing the document an
entity name is appended to the encoding name already in
the pool, and not surprisingly the resulting string is
not found in the entities table. The attached patch
fixes the bug.

Also this bug might cause trouble in other places,
where the temp2pool is used.

/Mike

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-22 12:49

Message:
Logged In: YES 
user_id=3066

Removed duplicate upload of test program.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 10:07

Message:
Logged In: YES 
user_id=290026

Thanks a lot!

Now it's up to you, Fred.

----------------------------------------------------------------------

Comment By: Mike Matsnev (haali)
Date: 2002-07-22 10:03

Message:
Logged In: YES 
user_id=287590

I wrote a simple test case that produces the output: "not
ok: undefined entity" before the fix, and "ok" after.

/Mike

----------------------------------------------------------------------

Comment By: Mike Matsnev (haali)
Date: 2002-07-22 10:03

Message:
Logged In: YES 
user_id=287590

I wrote a simple test case that produces the output: "not
ok: undefined entity" before the fix, and "ok" after.

/Mike

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 09:39

Message:
Logged In: YES 
user_id=290026

Assigned to Fred - he usually takes care of test cases.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 09:30

Message:
Logged In: YES 
user_id=290026

I think your assessment is correct. 
Thank you for your bug report.
Could you please supply a test case for that - obviously
you have come across the bug in a specific case.

I already applied the patch. Leaving this report open
until test case (hopefully :-)) supplied.

Karl

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584832&group_id=10127


From noreply@sourceforge.net  Mon Jul 22 10:51:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul 22 09:51:06 2002
Subject: [ expat-Bugs-584832 ] incorrect handling of internal entities
Message-ID: <E17WgOg-00036Q-00@usw-sf-web3.sourceforge.net>

Bugs item #584832, was opened at 2002-07-22 06:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584832&group_id=10127

Category: None
>Group: Test Required
Status: Open
Resolution: Accepted
Priority: 6
Submitted By: Mike Matsnev (haali)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: incorrect handling of internal entities

Initial Comment:
expat-1.95.4

Internal entities defined in the DTD are not properly
expanded in attribute values when an external encoding
handler is used. 

The cause of the problem is that a wrong pool is
cleared in processXmlDecl() and the encoding name
remains in the pool. When parsing the document an
entity name is appended to the encoding name already in
the pool, and not surprisingly the resulting string is
not found in the entities table. The attached patch
fixes the bug.

Also this bug might cause trouble in other places,
where the temp2pool is used.

/Mike

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-22 12:49

Message:
Logged In: YES 
user_id=3066

Removed duplicate upload of test program.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 10:07

Message:
Logged In: YES 
user_id=290026

Thanks a lot!

Now it's up to you, Fred.

----------------------------------------------------------------------

Comment By: Mike Matsnev (haali)
Date: 2002-07-22 10:03

Message:
Logged In: YES 
user_id=287590

I wrote a simple test case that produces the output: "not
ok: undefined entity" before the fix, and "ok" after.

/Mike

----------------------------------------------------------------------

Comment By: Mike Matsnev (haali)
Date: 2002-07-22 10:03

Message:
Logged In: YES 
user_id=287590

I wrote a simple test case that produces the output: "not
ok: undefined entity" before the fix, and "ok" after.

/Mike

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 09:39

Message:
Logged In: YES 
user_id=290026

Assigned to Fred - he usually takes care of test cases.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 09:30

Message:
Logged In: YES 
user_id=290026

I think your assessment is correct. 
Thank you for your bug report.
Could you please supply a test case for that - obviously
you have come across the bug in a specific case.

I already applied the patch. Leaving this report open
until test case (hopefully :-)) supplied.

Karl

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584832&group_id=10127


From noreply@sourceforge.net  Mon Jul 22 11:03:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul 22 10:03:06 2002
Subject: [ expat-Bugs-584041 ] Document handling of XML version
Message-ID: <E17WgaA-0004HP-00@usw-sf-web2.sourceforge.net>

Bugs item #584041, was opened at 2002-07-19 17:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584041&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Håkan Waara (hwaara)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Document handling of XML version

Initial Comment:
In the XML spec it says that the parser may throw a 
parser error if the version is not "1.0" in the XML 
declaration. This is also what IE6 does.

Here's a patch for this. It was diffed against mozilla.org's 
expat version, but I hope it can still be applied.

Thanks,  -Håkan

----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 13:02

Message:
Logged In: YES 
user_id=290026

Fred,

I wouldn't say you are a nobody <g>

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-22 12:42

Message:
Logged In: YES 
user_id=3066

Assigned to me and updated summary to reflect newfound
existence as a request for documentation.  Re-filed into the
"bug" tracker.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 12:29

Message:
Logged In: YES 
user_id=290026

I like the idea of leaving it to the application
to make the call: error or not.

Given the other arguments (mine included <g>)
I reverse my vote - I am now in favour of the status quo.

We will see what the experiences with the Mozilla 
version of Expat (where this patch comes from) will be ...

Karl

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-22 11:57

Message:
Logged In: YES 
user_id=3066

While I like being really picky about checking input, I
think there's a backward compatibility issue here.  To turn
version != "1.0" into an error, we break with expectations
established by previous releases.  Expat legacy does not
turn conditions into actual errors if it isn't necessary, so
"may" raise an error is not strong enough to go against
existing behavior.

If a particular application is interested in deteriming what
XML version was given, it may do so using
XML_SetXmlDeclHandler(), raising any sort of error
appropriate at that point.  This should be documented
(assign to me for docs once we reach agreement).

XML 1.1 feels sufficiently rough at this point that we don't
need to implement to it.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 09:43

Message:
Logged In: YES 
user_id=290026

One caveat though:

What will happen with XML 1.1 documents that
also conform to XML 1.0? Should the parser reject them?
That might potentially exclude many "good" documents.

Maybe an option should be added to turn version
number errors of.

Karl

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 21:58

Message:
Logged In: YES 
user_id=290026

The patch didn't work for me, but I applied it manually
against my copy of the current CVS (xmltok.c 1.20) 
- with small cosmetic changes.

Attached as xmltok.diff.

I am in favour of it. Let's see what the others say.

Karl

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 11:59

Message:
Logged In: YES 
user_id=290026

Yes, I have read the spec too.
I also read about the XML 1.1 spec making it a requirement.

I am just putting it up for discussion.
Why don't you post to the expat-discuss list?

Karl

----------------------------------------------------------------------

Comment By: Håkan Waara (hwaara)
Date: 2002-07-20 11:51

Message:
Logged In: YES 
user_id=72743

From noreply@sourceforge.net  Mon Jul 22 11:17:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon Jul 22 10:17:04 2002
Subject: [ expat-Bugs-584832 ] incorrect handling of internal entities
Message-ID: <E17Wgnk-0006J8-00@usw-sf-web4.sourceforge.net>

Bugs item #584832, was opened at 2002-07-22 06:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584832&group_id=10127

Category: None
Group: Test Required
>Status: Closed
Resolution: Accepted
Priority: 6
Submitted By: Mike Matsnev (haali)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: incorrect handling of internal entities

Initial Comment:
expat-1.95.4

Internal entities defined in the DTD are not properly
expanded in attribute values when an external encoding
handler is used. 

The cause of the problem is that a wrong pool is
cleared in processXmlDecl() and the encoding name
remains in the pool. When parsing the document an
entity name is appended to the encoding name already in
the pool, and not surprisingly the resulting string is
not found in the entities table. The attached patch
fixes the bug.

Also this bug might cause trouble in other places,
where the temp2pool is used.

/Mike

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-22 13:16

Message:
Logged In: YES 
user_id=3066

Integrated contributed test in tests/runtests.c revision
1.25.  Thanks!

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-22 12:49

Message:
Logged In: YES 
user_id=3066

Removed duplicate upload of test program.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 10:07

Message:
Logged In: YES 
user_id=290026

Thanks a lot!

Now it's up to you, Fred.

----------------------------------------------------------------------

Comment By: Mike Matsnev (haali)
Date: 2002-07-22 10:03

Message:
Logged In: YES 
user_id=287590

I wrote a simple test case that produces the output: "not
ok: undefined entity" before the fix, and "ok" after.

/Mike

----------------------------------------------------------------------

Comment By: Mike Matsnev (haali)
Date: 2002-07-22 10:03

Message:
Logged In: YES 
user_id=287590

I wrote a simple test case that produces the output: "not
ok: undefined entity" before the fix, and "ok" after.

/Mike

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 09:39

Message:
Logged In: YES 
user_id=290026

Assigned to Fred - he usually takes care of test cases.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-22 09:30

Message:
Logged In: YES 
user_id=290026

I think your assessment is correct. 
Thank you for your bug report.
Could you please supply a test case for that - obviously
you have come across the bug in a specific case.

I already applied the patch. Leaving this report open
until test case (hopefully :-)) supplied.

Karl

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584832&group_id=10127


From rvtAmyWilson@odesa.com  Mon Jul 22 15:41:02 2002
From: rvtAmyWilson@odesa.com (qrnbCustomer Support)
Date: Mon Jul 22 14:41:02 2002
Subject: Photoshop,Office,QuickBooks,WindowsME vvxs
Message-ID: <E17WkuB-0000uF-00@usw-sf-list1.sourceforge.net>

An HTML attachment was scrubbed...
URL: http://mail.libexpat.org/pipermail-21/expat-bugs/attachments/20020722/2f5ee36a/attachment.html
From noreply@sourceforge.net  Tue Jul 23 11:42:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul 23 10:42:05 2002
Subject: [ expat-Bugs-585521 ] Line ends not normalized for default
Message-ID: <E17X3fb-0006lc-00@usw-sf-web2.sourceforge.net>

Bugs item #585521, was opened at 2002-07-23 13:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585521&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: Line ends not normalized for default

Initial Comment:
Line endings passed to the handler set by
XML_SetDefaultHandler() or
XML_SetDefaultHandlerExpand() are not normalized,
though it appears they should be.

This definately seems to be a bug, but I'm not sure
that fixing it won't cause application breakage for
apps that determined they need to normalize line
endings themselves.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585521&group_id=10127


From noreply@sourceforge.net  Tue Jul 23 12:03:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul 23 11:03:02 2002
Subject: [ expat-Bugs-585521 ] Line ends not normalized for default
Message-ID: <E17X3z3-0006Ja-00@usw-sf-web3.sourceforge.net>

Bugs item #585521, was opened at 2002-07-23 13:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585521&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: Line ends not normalized for default

Initial Comment:
Line endings passed to the handler set by
XML_SetDefaultHandler() or
XML_SetDefaultHandlerExpand() are not normalized,
though it appears they should be.

This definately seems to be a bug, but I'm not sure
that fixing it won't cause application breakage for
apps that determined they need to normalize line
endings themselves.

----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-23 14:02

Message:
Logged In: YES 
user_id=290026

I don't think it is a bug in the implementation.
It might be a documentation problem.

If you look at how it is implemented and called,
it seems pretty clear that it intentionally reports
the raw input data (except for encoding).

There is also the XML_DefaultCurrent function,
which seems to require this behaviour.
Btw, this function does not seem to be documented
in reference.html.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585521&group_id=10127


From noreply@sourceforge.net  Tue Jul 23 12:18:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul 23 11:18:04 2002
Subject: [ expat-Bugs-585537 ] XML_DefaultCurrent() not documented
Message-ID: <E17X4Dm-0003LC-00@usw-sf-web4.sourceforge.net>

Bugs item #585537, was opened at 2002-07-23 14:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585537&group_id=10127

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: XML_DefaultCurrent() not documented

Initial Comment:
The XML_DefaultCurrent() function is not documented.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585537&group_id=10127


From noreply@sourceforge.net  Tue Jul 23 15:37:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul 23 14:37:05 2002
Subject: [ expat-Bugs-585521 ] Line ends not normalized for default
Message-ID: <E17X7Kz-0002id-00@usw-sf-web2.sourceforge.net>

Bugs item #585521, was opened at 2002-07-23 13:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585521&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: Line ends not normalized for default

Initial Comment:
Line endings passed to the handler set by
XML_SetDefaultHandler() or
XML_SetDefaultHandlerExpand() are not normalized,
though it appears they should be.

This definately seems to be a bug, but I'm not sure
that fixing it won't cause application breakage for
apps that determined they need to normalize line
endings themselves.

----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-23 17:36

Message:
Logged In: YES 
user_id=290026

Fred,

I think you are right, it is a bug.
The spec seems to say that every character passed
to the application has to go through line break
normalization.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-23 14:02

Message:
Logged In: YES 
user_id=290026

I don't think it is a bug in the implementation.
It might be a documentation problem.

If you look at how it is implemented and called,
it seems pretty clear that it intentionally reports
the raw input data (except for encoding).

There is also the XML_DefaultCurrent function,
which seems to require this behaviour.
Btw, this function does not seem to be documented
in reference.html.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585521&group_id=10127


From sparkle1733r70@domeus.co.uk  Tue Jul 23 21:06:02 2002
From: sparkle1733r70@domeus.co.uk (sparkle1733r70@domeus.co.uk)
Date: Tue Jul 23 20:06:02 2002
Subject: Best Investment For 2002 Should Be Energy                                                         0135xnKk6-246t-13
Message-ID: <028d15c33d4d$8271c1e7$4aa18eb2@mwrlml>

Powerful Profits Await YOU In The ENERGY Markets!!!
Fortunes will literally be made in the next few months!
Summer Driving Vacations alone will drive gas prices up very soon!

Unlock the Doors to STAGGERING PROFITS!
Take Advantage of Market Trends As They Happen!

NOW is the Time to Embrace The ENERGY Markets!
Commodity Trading Makes Millions Every Day!

*We all NEED ENERGY...every day!
*We all USE Energy...every day!
*Your Life Resolves around ENERGY!
*Every Major Country in the world consumes ENERGY daily!

The Five Major Energy Markets are:
*Unleaded Gasoline
*Electricity
*Natural Gas
*Heating Oil
*Crude Oil

Prices reach extremes for reasons...
Do you want to know the reasons WHY?
Get Your FREE Energy Investment Information Packet at:
http://www.energy-page.com/Energy_We_All_Use_it

OPEC announced 11/1/01 they would be cutting oil production
because prices were just too low.  OPEC AGAIN announced
on 12/28/01 to cut production another 6% starting 1/1/02!

"The Department of Energy says that the national average price
of a gallon of unleaded regular gasoline has soared 25 percent
this year, and is currently $1.37, up from $1.22 on March 11.
That's a 12 percent increase in three weeks. Prices are expected
to rise even further when the summer driving season gets underway."
(ABCNews.Com) 4/03/02

Gasoline prices and crude oil prices are now rising again,
and showing up at your neighborhood gas station with higher
prices. Let us show you how to profit from these price movements!

We can show you how many of our clients have turned a small
investment of only $10,000 into $50,000 or MORE in a very short
period of time!  Isn't everyone looking for YIELDS like that?
($5,000 Minimum Investment)

HOW? Because WE ARE "The Energy Experts" and we are truly
Energy Market Specialists. We KNOW the Energy Markets!

We are an experienced, professional firm with over 25 years of
experience. Learn how our clients get the best results, and
receive the most professional care in the investment world today!

Prices reach extremes for reasons...
Do you want to know the reasons WHY?
Get Your FREE Energy Investment Information Packet at:
http://www.energy-page.com/Energy_We_All_Use_it


-----------------------------
(Opt-Out Instructions)
You have received this email by either requesting more
information on one of our investment opportunities or someone may
have used your email address. To be removed from our mailing list
and to be automatically removed from any future mailings,
Just go to:  http://www.energy-page.com/takemeoff
-and Submit a Request for Opt-Out!

1329TdlB0-749gkEE4837vRaS2-431VHyo7433WaWf1-586FEfB7129qAMl55
8574xTpk0-430xxpc5716NNrq8-318Ffl30


From noreply@sourceforge.net  Tue Jul 23 21:19:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul 23 20:19:02 2002
Subject: [ expat-Bugs-585521 ] Line ends not normalized for default
Message-ID: <E17XCfE-0001Bn-00@usw-sf-web2.sourceforge.net>

Bugs item #585521, was opened at 2002-07-23 13:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585521&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: Line ends not normalized for default

Initial Comment:
Line endings passed to the handler set by
XML_SetDefaultHandler() or
XML_SetDefaultHandlerExpand() are not normalized,
though it appears they should be.

This definately seems to be a bug, but I'm not sure
that fixing it won't cause application breakage for
apps that determined they need to normalize line
endings themselves.

----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-23 23:18

Message:
Logged In: YES 
user_id=290026

Fixing this bug should only be a problem for
applications that *need* the default handler's data
un-normalized. Otherwise, normalizing the linebreaks
a second time would not change them.



----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-23 17:36

Message:
Logged In: YES 
user_id=290026

Fred,

I think you are right, it is a bug.
The spec seems to say that every character passed
to the application has to go through line break
normalization.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-23 14:02

Message:
Logged In: YES 
user_id=290026

I don't think it is a bug in the implementation.
It might be a documentation problem.

If you look at how it is implemented and called,
it seems pretty clear that it intentionally reports
the raw input data (except for encoding).

There is also the XML_DefaultCurrent function,
which seems to require this behaviour.
Btw, this function does not seem to be documented
in reference.html.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585521&group_id=10127


From noreply@sourceforge.net  Tue Jul 23 22:00:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue Jul 23 21:00:07 2002
Subject: [ expat-Bugs-585521 ] Line ends not normalized for default
Message-ID: <E17XDJY-0002sQ-00@usw-sf-web1.sourceforge.net>

Bugs item #585521, was opened at 2002-07-23 13:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585521&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: Line ends not normalized for default

Initial Comment:
Line endings passed to the handler set by
XML_SetDefaultHandler() or
XML_SetDefaultHandlerExpand() are not normalized,
though it appears they should be.

This definately seems to be a bug, but I'm not sure
that fixing it won't cause application breakage for
apps that determined they need to normalize line
endings themselves.

----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-23 23:59

Message:
Logged In: YES 
user_id=290026

Getting the raw data may be exactly the case the default 
handler is meant for. The existence of XML_DefaultCurrent
would support this assumption. Check the corresponding 
documentation/comments in expat.h.


----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-23 23:18

Message:
Logged In: YES 
user_id=290026

Fixing this bug should only be a problem for
applications that *need* the default handler's data
un-normalized. Otherwise, normalizing the linebreaks
a second time would not change them.



----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-23 17:36

Message:
Logged In: YES 
user_id=290026

Fred,

I think you are right, it is a bug.
The spec seems to say that every character passed
to the application has to go through line break
normalization.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-23 14:02

Message:
Logged In: YES 
user_id=290026

I don't think it is a bug in the implementation.
It might be a documentation problem.

If you look at how it is implemented and called,
it seems pretty clear that it intentionally reports
the raw input data (except for encoding).

There is also the XML_DefaultCurrent function,
which seems to require this behaviour.
Btw, this function does not seem to be documented
in reference.html.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585521&group_id=10127


From noreply@sourceforge.net  Thu Jul 25 17:47:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu Jul 25 16:47:02 2002
Subject: [ expat-Bugs-585521 ] Line ends not normalized for default
Message-ID: <E17XsJ9-0002f4-00@usw-sf-web2.sourceforge.net>

Bugs item #585521, was opened at 2002-07-23 13:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585521&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: Line ends not normalized for default

Initial Comment:
Line endings passed to the handler set by
XML_SetDefaultHandler() or
XML_SetDefaultHandlerExpand() are not normalized,
though it appears they should be.

This definately seems to be a bug, but I'm not sure
that fixing it won't cause application breakage for
apps that determined they need to normalize line
endings themselves.

----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-25 19:46

Message:
Logged In: YES 
user_id=290026

Apart from the comment in expat.h, what sense would
an alternate handler make if it did what the other handlers
already do?

If we agree that it should normalize linebreaks, should
it then not also expand character and predefined entity 
references? But wait, that should not be done in all 
situations, since reporting default attribute values does not
allow expanding general entities. Then we would need
a special behaviour when called instead of an attribute list
declaration handler. Why not use the proper handler then?

The default handler callback must provide something that
the regular handlers don't do, otherwise I don't see why 
anyone would use it.
And what could that be? Reporting the raw data
seems the most reasonable, IMO. The need for additional
processing is obvious in any case, so why not refrain
from pre-processing altogether (with the exception of 
encoding, which is reversible anyway).



----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-23 23:59

Message:
Logged In: YES 
user_id=290026

Getting the raw data may be exactly the case the default 
handler is meant for. The existence of XML_DefaultCurrent
would support this assumption. Check the corresponding 
documentation/comments in expat.h.


----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-23 23:18

Message:
Logged In: YES 
user_id=290026

Fixing this bug should only be a problem for
applications that *need* the default handler's data
un-normalized. Otherwise, normalizing the linebreaks
a second time would not change them.



----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-23 17:36

Message:
Logged In: YES 
user_id=290026

Fred,

I think you are right, it is a bug.
The spec seems to say that every character passed
to the application has to go through line break
normalization.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-23 14:02

Message:
Logged In: YES 
user_id=290026

I don't think it is a bug in the implementation.
It might be a documentation problem.

If you look at how it is implemented and called,
it seems pretty clear that it intentionally reports
the raw input data (except for encoding).

There is also the XML_DefaultCurrent function,
which seems to require this behaviour.
Btw, this function does not seem to be documented
in reference.html.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585521&group_id=10127


From noreply@sourceforge.net  Thu Jul 25 17:48:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu Jul 25 16:48:03 2002
Subject: [ expat-Bugs-585537 ] XML_DefaultCurrent() not documented
Message-ID: <E17XsKi-0006Pt-00@usw-sf-web4.sourceforge.net>

Bugs item #585537, was opened at 2002-07-23 14:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585537&group_id=10127

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: XML_DefaultCurrent() not documented

Initial Comment:
The XML_DefaultCurrent() function is not documented.

----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-25 19:47

Message:
Logged In: YES 
user_id=290026

I would like to add here:
The documentation for the default handler should be
improved too, to be in sync with the comments in expat.h.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585537&group_id=10127


From noreply@sourceforge.net  Fri Jul 26 13:47:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 26 12:47:05 2002
Subject: [ expat-Bugs-587211 ] make error
Message-ID: <E17YB39-00057Y-00@usw-sf-web5.sourceforge.net>

Bugs item #587211, was opened at 2002-07-26 12:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=587211&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: make error

Initial Comment:
seaport:/tmp/expat-1.95.4# make
/usr/bin/bash ./libtool --silent --mode=link gcc -g -O2 -
Wall -Wmissing-prototypes -Wstrict-prototypes   -I./lib -
I.  -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o 
xmlwf/codepage.o xmlwf/unixfilemap.o libexpat.la
xmlwf/xmlfile.o: Undefined symbol `_open' referenced 
(use -lc ?)
xmlwf/xmlfile.o: Undefined symbol `_close' referenced 
(use -lc ?)
xmlwf/xmlfile.o: Undefined symbol `_read' referenced 
(use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_open' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_fstat' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_close' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_munmap' 
referenced (use -lc ?)
ld: Spurious undefined symbols: # undefined symbols 5, 
reported 0
*** Error code 1

Stop.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=587211&group_id=10127


From noreply@sourceforge.net  Fri Jul 26 13:53:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 26 12:53:03 2002
Subject: [ expat-Bugs-587211 ] make error
Message-ID: <E17YB8s-0006EN-00@usw-sf-web1.sourceforge.net>

Bugs item #587211, was opened at 2002-07-26 15:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=587211&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: make error

Initial Comment:
seaport:/tmp/expat-1.95.4# make
/usr/bin/bash ./libtool --silent --mode=link gcc -g -O2 -
Wall -Wmissing-prototypes -Wstrict-prototypes   -I./lib -
I.  -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o 
xmlwf/codepage.o xmlwf/unixfilemap.o libexpat.la
xmlwf/xmlfile.o: Undefined symbol `_open' referenced 
(use -lc ?)
xmlwf/xmlfile.o: Undefined symbol `_close' referenced 
(use -lc ?)
xmlwf/xmlfile.o: Undefined symbol `_read' referenced 
(use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_open' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_fstat' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_close' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_munmap' 
referenced (use -lc ?)
ld: Spurious undefined symbols: # undefined symbols 5, 
reported 0
*** Error code 1

Stop.


----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-26 15:52

Message:
Logged In: YES 
user_id=290026

Without more information we will
need to close this report without action.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=587211&group_id=10127


From noreply@sourceforge.net  Fri Jul 26 14:00:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 26 13:00:07 2002
Subject: [ expat-Bugs-587211 ] make error
Message-ID: <E17YBFU-0005LV-00@usw-sf-web5.sourceforge.net>

Bugs item #587211, was opened at 2002-07-26 19:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=587211&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: make error

Initial Comment:
seaport:/tmp/expat-1.95.4# make
/usr/bin/bash ./libtool --silent --mode=link gcc -g -O2 -
Wall -Wmissing-prototypes -Wstrict-prototypes   -I./lib -
I.  -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o 
xmlwf/codepage.o xmlwf/unixfilemap.o libexpat.la
xmlwf/xmlfile.o: Undefined symbol `_open' referenced 
(use -lc ?)
xmlwf/xmlfile.o: Undefined symbol `_close' referenced 
(use -lc ?)
xmlwf/xmlfile.o: Undefined symbol `_read' referenced 
(use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_open' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_fstat' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_close' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_munmap' 
referenced (use -lc ?)
ld: Spurious undefined symbols: # undefined symbols 5, 
reported 0
*** Error code 1

Stop.


----------------------------------------------------------------------

Comment By: Dave Reinhardt (thepair)
Date: 2002-07-26 19:59

Message:
Logged In: YES 
user_id=53868

what kind of additional info please

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-26 19:52

Message:
Logged In: YES 
user_id=290026

Without more information we will
need to close this report without action.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=587211&group_id=10127


From noreply@sourceforge.net  Fri Jul 26 14:08:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 26 13:08:02 2002
Subject: [ expat-Bugs-587211 ] make error
Message-ID: <E17YBMh-0005T6-00@usw-sf-web5.sourceforge.net>

Bugs item #587211, was opened at 2002-07-26 15:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=587211&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: make error

Initial Comment:
seaport:/tmp/expat-1.95.4# make
/usr/bin/bash ./libtool --silent --mode=link gcc -g -O2 -
Wall -Wmissing-prototypes -Wstrict-prototypes   -I./lib -
I.  -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o 
xmlwf/codepage.o xmlwf/unixfilemap.o libexpat.la
xmlwf/xmlfile.o: Undefined symbol `_open' referenced 
(use -lc ?)
xmlwf/xmlfile.o: Undefined symbol `_close' referenced 
(use -lc ?)
xmlwf/xmlfile.o: Undefined symbol `_read' referenced 
(use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_open' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_fstat' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_close' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_munmap' 
referenced (use -lc ?)
ld: Spurious undefined symbols: # undefined symbols 5, 
reported 0
*** Error code 1

Stop.


----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-26 16:07

Message:
Logged In: YES 
user_id=290026

Everything we need to know to be able
to reproduce your problem. Obviously
it works for us, so where should we start?

What OS/platform? Which version of it?
What compiler version?
What configuration - any changes or default?
etc., etc.



----------------------------------------------------------------------

Comment By: Dave Reinhardt (thepair)
Date: 2002-07-26 15:59

Message:
Logged In: YES 
user_id=53868

what kind of additional info please

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-26 15:52

Message:
Logged In: YES 
user_id=290026

Without more information we will
need to close this report without action.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=587211&group_id=10127


From noreply@sourceforge.net  Fri Jul 26 14:41:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 26 13:41:03 2002
Subject: [ expat-Bugs-587211 ] make error
Message-ID: <E17YBt7-000771-00@usw-sf-web1.sourceforge.net>

Bugs item #587211, was opened at 2002-07-26 19:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=587211&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: make error

Initial Comment:
seaport:/tmp/expat-1.95.4# make
/usr/bin/bash ./libtool --silent --mode=link gcc -g -O2 -
Wall -Wmissing-prototypes -Wstrict-prototypes   -I./lib -
I.  -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o 
xmlwf/codepage.o xmlwf/unixfilemap.o libexpat.la
xmlwf/xmlfile.o: Undefined symbol `_open' referenced 
(use -lc ?)
xmlwf/xmlfile.o: Undefined symbol `_close' referenced 
(use -lc ?)
xmlwf/xmlfile.o: Undefined symbol `_read' referenced 
(use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_open' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_fstat' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_close' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_munmap' 
referenced (use -lc ?)
ld: Spurious undefined symbols: # undefined symbols 5, 
reported 0
*** Error code 1

Stop.


----------------------------------------------------------------------

Comment By: Dave Reinhardt (thepair)
Date: 2002-07-26 20:40

Message:
Logged In: YES 
user_id=53868

What OS/platform? Which version of it?
 PowerBSD Virtual Operating System v2.1 ELF-RELEASE 
(216.94.9.250) (ttyp0)
 PowerBSD v2.0-BETA - Copyright (c) 1997, 1998 Innosolve 
Systems Inc.

What compiler version?
can you tell from the output of the ./config command?
loading cache ./config.cache
checking host system type... i386-unknown-freebsd3.0
checking build system type... i386-unknown-freebsd3.0
checking for ranlib... (cached) ranlib
checking for gcc... (cached) gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-
compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for ld used by GCC... (cached) /usr/libexec/aout/ld
checking if the linker (/usr/libexec/aout/ld) is GNU ld... 
(cached) no
checking for BSD-compatible nm... (cached) /nfs/usr/bin/nm -
p
checking whether ln -s works... (cached) yes
updating cache ./config.cache
loading cache ./config.cache within ltconfig
checking for object suffix... o
checking for executable suffix... (cached) no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC 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 ... no
checking if gcc static flag -static works... -static
checking if the linker (/usr/libexec/aout/ld) is GNU ld... no
checking whether the linker (/usr/libexec/aout/ld) supports 
shared libraries... yes
checking command to parse /nfs/usr/bin/nm -p output... ok
checking how to hardcode library paths into programs... 
immediate
checking for /usr/libexec/aout/ld option to reload object 
files... -r
checking dynamic linker characteristics... freebsd3.0 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) gcc
checking whether the C compiler (gcc -g -O2 ) works... yes
checking whether the C compiler (gcc -g -O2 ) is a cross-
compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for a BSD compatible install... 
(cached) /nfs/usr/bin/install -c
checking how to run the C preprocessor... (cached) gcc -E
checking for ANSI C header files... (cached) yes
checking for fcntl.h... (cached) yes
checking for unistd.h... (cached) yes
checking whether byte ordering is bigendian... (cached) no
checking for working const... (cached) yes
checking for off_t... (cached) yes
checking for size_t... (cached) yes
checking for 8-bit clean memcmp... (cached) yes
checking for unistd.h... (cached) yes
checking for getpagesize... (cached) yes
checking for working mmap... (cached) yes
checking for memmove... (cached) yes
checking for bcopy... (cached) yes
updating cache ./config.cache
creating ./config.status
creating Makefile
creating lib/Makefile
creating xmlwf/Makefile
creating examples/Makefile
creating config.h
config.h is unchanged

make
cd lib; make
/bin/sh ../libtool --mode=link  gcc -version-info 0:0:0 -g -O2  -o 
libexpat.la -rpath /usr/local/lib  xmlparse.lo xmltok.lo 
xmlrole.lo
rm -fr .libs/libexpat.la .libs/libexpat.* .libs/libexpat.*
(cd . && ln -s xmlparse.lo xmlparse.o)
*** Error code 1

Stop.
*** Error code 1
What configuration - any changes or default? default
This is not assumed to be a bug. It is something about the 
way I am doing it or the fact that I do not have root access to 
the server. Only root to my virtual server. I have successfully 
installed others.
etc., etc.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-26 20:07

Message:
Logged In: YES 
user_id=290026

Everything we need to know to be able
to reproduce your problem. Obviously
it works for us, so where should we start?

What OS/platform? Which version of it?
What compiler version?
What configuration - any changes or default?
etc., etc.



----------------------------------------------------------------------

Comment By: Dave Reinhardt (thepair)
Date: 2002-07-26 19:59

Message:
Logged In: YES 
user_id=53868

what kind of additional info please

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-26 19:52

Message:
Logged In: YES 
user_id=290026

Without more information we will
need to close this report without action.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=587211&group_id=10127


From noreply@sourceforge.net  Fri Jul 26 14:44:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 26 13:44:02 2002
Subject: [ expat-Bugs-587211 ] make error
Message-ID: <E17YBvj-0007MH-00@usw-sf-web2.sourceforge.net>

Bugs item #587211, was opened at 2002-07-26 19:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=587211&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: make error

Initial Comment:
seaport:/tmp/expat-1.95.4# make
/usr/bin/bash ./libtool --silent --mode=link gcc -g -O2 -
Wall -Wmissing-prototypes -Wstrict-prototypes   -I./lib -
I.  -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o 
xmlwf/codepage.o xmlwf/unixfilemap.o libexpat.la
xmlwf/xmlfile.o: Undefined symbol `_open' referenced 
(use -lc ?)
xmlwf/xmlfile.o: Undefined symbol `_close' referenced 
(use -lc ?)
xmlwf/xmlfile.o: Undefined symbol `_read' referenced 
(use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_open' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_fstat' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_close' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_munmap' 
referenced (use -lc ?)
ld: Spurious undefined symbols: # undefined symbols 5, 
reported 0
*** Error code 1

Stop.


----------------------------------------------------------------------

Comment By: Dave Reinhardt (thepair)
Date: 2002-07-26 20:43

Message:
Logged In: YES 
user_id=53868

seaport:/tmp/expat-1.95.0# which gcc
/nfs/usr/bin/gcc
seaport:/tmp/expat-1.95.0# gcc -v
gcc version 2.7.2.1


----------------------------------------------------------------------

Comment By: Dave Reinhardt (thepair)
Date: 2002-07-26 20:40

Message:
Logged In: YES 
user_id=53868

What OS/platform? Which version of it?
 PowerBSD Virtual Operating System v2.1 ELF-RELEASE 
(216.94.9.250) (ttyp0)
 PowerBSD v2.0-BETA - Copyright (c) 1997, 1998 Innosolve 
Systems Inc.

What compiler version?
can you tell from the output of the ./config command?
loading cache ./config.cache
checking host system type... i386-unknown-freebsd3.0
checking build system type... i386-unknown-freebsd3.0
checking for ranlib... (cached) ranlib
checking for gcc... (cached) gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-
compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for ld used by GCC... (cached) /usr/libexec/aout/ld
checking if the linker (/usr/libexec/aout/ld) is GNU ld... 
(cached) no
checking for BSD-compatible nm... (cached) /nfs/usr/bin/nm -
p
checking whether ln -s works... (cached) yes
updating cache ./config.cache
loading cache ./config.cache within ltconfig
checking for object suffix... o
checking for executable suffix... (cached) no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC 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 ... no
checking if gcc static flag -static works... -static
checking if the linker (/usr/libexec/aout/ld) is GNU ld... no
checking whether the linker (/usr/libexec/aout/ld) supports 
shared libraries... yes
checking command to parse /nfs/usr/bin/nm -p output... ok
checking how to hardcode library paths into programs... 
immediate
checking for /usr/libexec/aout/ld option to reload object 
files... -r
checking dynamic linker characteristics... freebsd3.0 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) gcc
checking whether the C compiler (gcc -g -O2 ) works... yes
checking whether the C compiler (gcc -g -O2 ) is a cross-
compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for a BSD compatible install... 
(cached) /nfs/usr/bin/install -c
checking how to run the C preprocessor... (cached) gcc -E
checking for ANSI C header files... (cached) yes
checking for fcntl.h... (cached) yes
checking for unistd.h... (cached) yes
checking whether byte ordering is bigendian... (cached) no
checking for working const... (cached) yes
checking for off_t... (cached) yes
checking for size_t... (cached) yes
checking for 8-bit clean memcmp... (cached) yes
checking for unistd.h... (cached) yes
checking for getpagesize... (cached) yes
checking for working mmap... (cached) yes
checking for memmove... (cached) yes
checking for bcopy... (cached) yes
updating cache ./config.cache
creating ./config.status
creating Makefile
creating lib/Makefile
creating xmlwf/Makefile
creating examples/Makefile
creating config.h
config.h is unchanged

make
cd lib; make
/bin/sh ../libtool --mode=link  gcc -version-info 0:0:0 -g -O2  -o 
libexpat.la -rpath /usr/local/lib  xmlparse.lo xmltok.lo 
xmlrole.lo
rm -fr .libs/libexpat.la .libs/libexpat.* .libs/libexpat.*
(cd . && ln -s xmlparse.lo xmlparse.o)
*** Error code 1

Stop.
*** Error code 1
What configuration - any changes or default? default
This is not assumed to be a bug. It is something about the 
way I am doing it or the fact that I do not have root access to 
the server. Only root to my virtual server. I have successfully 
installed others.
etc., etc.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-26 20:07

Message:
Logged In: YES 
user_id=290026

Everything we need to know to be able
to reproduce your problem. Obviously
it works for us, so where should we start?

What OS/platform? Which version of it?
What compiler version?
What configuration - any changes or default?
etc., etc.



----------------------------------------------------------------------

Comment By: Dave Reinhardt (thepair)
Date: 2002-07-26 19:59

Message:
Logged In: YES 
user_id=53868

what kind of additional info please

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-26 19:52

Message:
Logged In: YES 
user_id=290026

Without more information we will
need to close this report without action.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=587211&group_id=10127


From noreply@sourceforge.net  Fri Jul 26 14:50:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri Jul 26 13:50:03 2002
Subject: [ expat-Bugs-587211 ] make error
Message-ID: <E17YC1j-0007Jp-00@usw-sf-web1.sourceforge.net>

Bugs item #587211, was opened at 2002-07-26 15:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=587211&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: make error

Initial Comment:
seaport:/tmp/expat-1.95.4# make
/usr/bin/bash ./libtool --silent --mode=link gcc -g -O2 -
Wall -Wmissing-prototypes -Wstrict-prototypes   -I./lib -
I.  -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o 
xmlwf/codepage.o xmlwf/unixfilemap.o libexpat.la
xmlwf/xmlfile.o: Undefined symbol `_open' referenced 
(use -lc ?)
xmlwf/xmlfile.o: Undefined symbol `_close' referenced 
(use -lc ?)
xmlwf/xmlfile.o: Undefined symbol `_read' referenced 
(use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_open' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_fstat' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_close' 
referenced (use -lc ?)
xmlwf/unixfilemap.o: Undefined symbol `_munmap' 
referenced (use -lc ?)
ld: Spurious undefined symbols: # undefined symbols 5, 
reported 0
*** Error code 1

Stop.


----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-26 16:49

Message:
Logged In: YES 
user_id=290026

Fred,

maybe you can help.

----------------------------------------------------------------------

Comment By: Dave Reinhardt (thepair)
Date: 2002-07-26 16:43

Message:
Logged In: YES 
user_id=53868

seaport:/tmp/expat-1.95.0# which gcc
/nfs/usr/bin/gcc
seaport:/tmp/expat-1.95.0# gcc -v
gcc version 2.7.2.1


----------------------------------------------------------------------

Comment By: Dave Reinhardt (thepair)
Date: 2002-07-26 16:40

Message:
Logged In: YES 
user_id=53868

What OS/platform? Which version of it?
 PowerBSD Virtual Operating System v2.1 ELF-RELEASE 
(216.94.9.250) (ttyp0)
 PowerBSD v2.0-BETA - Copyright (c) 1997, 1998 Innosolve 
Systems Inc.

What compiler version?
can you tell from the output of the ./config command?
loading cache ./config.cache
checking host system type... i386-unknown-freebsd3.0
checking build system type... i386-unknown-freebsd3.0
checking for ranlib... (cached) ranlib
checking for gcc... (cached) gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-
compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for ld used by GCC... (cached) /usr/libexec/aout/ld
checking if the linker (/usr/libexec/aout/ld) is GNU ld... 
(cached) no
checking for BSD-compatible nm... (cached) /nfs/usr/bin/nm -
p
checking whether ln -s works... (cached) yes
updating cache ./config.cache
loading cache ./config.cache within ltconfig
checking for object suffix... o
checking for executable suffix... (cached) no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC 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 ... no
checking if gcc static flag -static works... -static
checking if the linker (/usr/libexec/aout/ld) is GNU ld... no
checking whether the linker (/usr/libexec/aout/ld) supports 
shared libraries... yes
checking command to parse /nfs/usr/bin/nm -p output... ok
checking how to hardcode library paths into programs... 
immediate
checking for /usr/libexec/aout/ld option to reload object 
files... -r
checking dynamic linker characteristics... freebsd3.0 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) gcc
checking whether the C compiler (gcc -g -O2 ) works... yes
checking whether the C compiler (gcc -g -O2 ) is a cross-
compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for a BSD compatible install... 
(cached) /nfs/usr/bin/install -c
checking how to run the C preprocessor... (cached) gcc -E
checking for ANSI C header files... (cached) yes
checking for fcntl.h... (cached) yes
checking for unistd.h... (cached) yes
checking whether byte ordering is bigendian... (cached) no
checking for working const... (cached) yes
checking for off_t... (cached) yes
checking for size_t... (cached) yes
checking for 8-bit clean memcmp... (cached) yes
checking for unistd.h... (cached) yes
checking for getpagesize... (cached) yes
checking for working mmap... (cached) yes
checking for memmove... (cached) yes
checking for bcopy... (cached) yes
updating cache ./config.cache
creating ./config.status
creating Makefile
creating lib/Makefile
creating xmlwf/Makefile
creating examples/Makefile
creating config.h
config.h is unchanged

make
cd lib; make
/bin/sh ../libtool --mode=link  gcc -version-info 0:0:0 -g -O2  -o 
libexpat.la -rpath /usr/local/lib  xmlparse.lo xmltok.lo 
xmlrole.lo
rm -fr .libs/libexpat.la .libs/libexpat.* .libs/libexpat.*
(cd . && ln -s xmlparse.lo xmlparse.o)
*** Error code 1

Stop.
*** Error code 1
What configuration - any changes or default? default
This is not assumed to be a bug. It is something about the 
way I am doing it or the fact that I do not have root access to 
the server. Only root to my virtual server. I have successfully 
installed others.
etc., etc.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-26 16:07

Message:
Logged In: YES 
user_id=290026

Everything we need to know to be able
to reproduce your problem. Obviously
it works for us, so where should we start?

What OS/platform? Which version of it?
What compiler version?
What configuration - any changes or default?
etc., etc.



----------------------------------------------------------------------

Comment By: Dave Reinhardt (thepair)
Date: 2002-07-26 15:59

Message:
Logged In: YES 
user_id=53868

what kind of additional info please

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-26 15:52

Message:
Logged In: YES 
user_id=290026

Without more information we will
need to close this report without action.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=587211&group_id=10127


From noreply@sourceforge.net  Sat Jul 27 09:56:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat Jul 27 08:56:02 2002
Subject: [ expat-Bugs-570263 ] Bug with attr defaults and external PE's
Message-ID: <E17YTun-0006Dh-00@usw-sf-web3.sourceforge.net>

Bugs item #570263, was opened at 2002-06-17 19:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=570263&group_id=10127

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Rolf Ade (pointsman)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Bug with attr defaults and external PE's

Initial Comment:
Take a look at this document:

<!DOCTYPE doc [
 <!ATTLIST doc a CDATA "D4A">
 <!ENTITY % x SYSTEM "x.ent">
 %x;
 <!ATTLIST doc b CDATA "D4B">
 ]>
<doc>Hello.</doc>


If you process this with expat 1.95.3 and without
processing the external entity %x; expat reports the
element doc with two attributes: a="D4A" b="D4B".

You could easily check this with the xmlwf tool, using
the -d option.

This is wrong. See the last paragraph of the XML rec
Second Editoin 5.1: "[...][T]hey must not process
entity declarations or attribute-list declarations
encountered after a reference to a parameter entity
that is not read, since the entity may have contained
overriding declarations."

As far as I see, this bug was already in 1.95.1, then
fixed in 1.95.2 and showed up again in 1.95.3

rolf


----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-27 11:55

Message:
Logged In: YES 
user_id=290026

Closed, since it fixes the test case, and no complaints
have been received since release of 1.95.4.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-07 11:32

Message:
Logged In: YES 
user_id=290026

Small correction:
The file Rolf3_2.ent is actually not needed, since it
won't be read by Expat, but I attached it anyway.

Karl

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-07 11:22

Message:
Logged In: YES 
user_id=290026

Patch # 578161 includes a fix for this bug.
Please test.

I have also attached a test document (files Rolf3.xml,
Rolf3_1.ent and Rolf3_2.ent) which test section 5.1 for
entity declarations. There is an entity reference %z; in
Rolf3_1.ent which needs to be skipped, since there is
no declaration for it, and this is not a WF error.
More details in the comment within Rolf3.xml.

Karl

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-06-17 23:13

Message:
Logged In: YES 
user_id=290026

Yes, this is a bug, and was probably introduced by me.
Now I finally beging to understand why the dtd.complete flag
was used in such strange ways... :-(

So, I guess this one is for me,

Karl

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=570263&group_id=10127


From noreply@sourceforge.net  Sat Jul 27 09:58:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat Jul 27 08:58:02 2002
Subject: [ expat-Bugs-585521 ] Line ends not normalized for default
Message-ID: <E17YTwb-0006FG-00@usw-sf-web3.sourceforge.net>

Bugs item #585521, was opened at 2002-07-23 13:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585521&group_id=10127

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 4
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: Line ends not normalized for default

Initial Comment:
Line endings passed to the handler set by
XML_SetDefaultHandler() or
XML_SetDefaultHandlerExpand() are not normalized,
though it appears they should be.

This definately seems to be a bug, but I'm not sure
that fixing it won't cause application breakage for
apps that determined they need to normalize line
endings themselves.

----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-27 11:57

Message:
Logged In: YES 
user_id=290026

Closed and rejected, since Fred accepted my last argument,
and since no one else seemed to care.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-25 19:46

Message:
Logged In: YES 
user_id=290026

Apart from the comment in expat.h, what sense would
an alternate handler make if it did what the other handlers
already do?

If we agree that it should normalize linebreaks, should
it then not also expand character and predefined entity 
references? But wait, that should not be done in all 
situations, since reporting default attribute values does not
allow expanding general entities. Then we would need
a special behaviour when called instead of an attribute list
declaration handler. Why not use the proper handler then?

The default handler callback must provide something that
the regular handlers don't do, otherwise I don't see why 
anyone would use it.
And what could that be? Reporting the raw data
seems the most reasonable, IMO. The need for additional
processing is obvious in any case, so why not refrain
from pre-processing altogether (with the exception of 
encoding, which is reversible anyway).



----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-23 23:59

Message:
Logged In: YES 
user_id=290026

Getting the raw data may be exactly the case the default 
handler is meant for. The existence of XML_DefaultCurrent
would support this assumption. Check the corresponding 
documentation/comments in expat.h.


----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-23 23:18

Message:
Logged In: YES 
user_id=290026

Fixing this bug should only be a problem for
applications that *need* the default handler's data
un-normalized. Otherwise, normalizing the linebreaks
a second time would not change them.



----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-23 17:36

Message:
Logged In: YES 
user_id=290026

Fred,

I think you are right, it is a bug.
The spec seems to say that every character passed
to the application has to go through line break
normalization.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-23 14:02

Message:
Logged In: YES 
user_id=290026

I don't think it is a bug in the implementation.
It might be a documentation problem.

If you look at how it is implemented and called,
it seems pretty clear that it intentionally reports
the raw input data (except for encoding).

There is also the XML_DefaultCurrent function,
which seems to require this behaviour.
Btw, this function does not seem to be documented
in reference.html.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585521&group_id=10127


From noreply@sourceforge.net  Sat Jul 27 10:24:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat Jul 27 09:24:04 2002
Subject: [ expat-Patches-581069 ] Borland build files ver 1.95.4
Message-ID: <E17YULy-0004fF-00@usw-sf-web2.sourceforge.net>

Patches item #581069, was opened at 2002-07-13 15:08
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=581069&group_id=10127

Category: Documentation
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Patrick McConnell (pmcconnell)
Assigned to: Nobody/Anonymous (nobody)
Summary: Borland build files ver 1.95.4

Initial Comment:
The Borland project and make files included with 
vesion 1.95.4 contain 2 errors that prevent them from 
working. To fix this, delete all files in the 
expat\Source\BCB5 directory and replace them with 
the attached files.

----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-27 12:23

Message:
Logged In: YES 
user_id=290026

Patch applied.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=581069&group_id=10127


From noreply@sourceforge.net  Sat Jul 27 12:05:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat Jul 27 11:05:02 2002
Subject: [ expat-Bugs-580793 ] BCB5 Build does not work
Message-ID: <E17YVvd-0007qE-00@usw-sf-web3.sourceforge.net>

Bugs item #580793, was opened at 2002-07-12 17:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580793&group_id=10127

Category: Build control
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Karl Waclawek (kwaclaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: BCB5 Build does not work

Initial Comment:
I tried to build for the free command line version 
of Borland C++ Builder, but no luck.
Seems some of the directory references in
the make files don't match the CVS directory 
structure.

I have fixed this and also changed the main 
makefile where it uses DOS commands
 - deltree does not exist on W2K.

I also added a short ReadMe file.

Attached is a zip of the whole bcb5 directory.

Karl

----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-27 14:04

Message:
Logged In: YES 
user_id=290026

Patch # 581069 has been checked in, and additional
fixes have been applied to enable building Expat
under the free command line compiler BCC32.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580793&group_id=10127


From noreply@sourceforge.net  Sat Jul 27 17:16:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat Jul 27 16:16:01 2002
Subject: [ expat-Bugs-580503 ] 1.95.2 Reuses Buffer if isFinal != 0
Message-ID: <E17YamV-0002Gl-00@usw-sf-web2.sourceforge.net>

Bugs item #580503, was opened at 2002-07-12 05:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127

Category: Documentation
Group: None
>Status: Closed
Resolution: Rejected
Priority: 6
Submitted By: Ari Johnson (ari_j)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 1.95.2 Reuses Buffer if isFinal != 0

Initial Comment:
In expat 1.95.2 (the latest version for which a 
FreeBSD package is available), calling 
XML_ParseBuffer() or XML_Parse() with isFinal != 0 
causes the previously-parsed buffer to be parsed, 
at least partially, again.  For example, say that I'm 
sending it chunks of 1024 bytes at a time, and the 
last root tag of my XML file is <test>.  Let's say 
that the last buffer chunk I sent it was as follows:
--
<nodeN>value</nodeN>
<data/>
</test>
--
The next time I call XML_ParseBuffer() or XML_Parse
(), I get the full complement of startElement, 
endElement, and characterData events for 
<nodeN>.  This occurs after I've received the 
<test> endElement event.  Moreover, the error 
occurs whether I send len = 0 to XML_Parse*() or if I 
actually send data to it.

Is this a known bug?  Is it fixed in a newer version?  
I couldn't find any references to it on the bug list, 
open or closed; nor in the CVS log for xmlparser.c.


----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-27 19:15

Message:
Logged In: YES 
user_id=290026

Added a paragraph to reference.html that states that
the parsing functions must not be called recursively,
that is, from within a handler for the same parser that 
called the handler.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-20 11:38

Message:
Logged In: YES 
user_id=290026

Fred once indicated that documentation is one of his
interests. Anticipating that he is very eager to take care
of this issue, I am assigning it to him . <bg>

Karl

----------------------------------------------------------------------

Comment By: Ari Johnson (ari_j)
Date: 2002-07-13 02:10

Message:
Logged In: YES 
user_id=90811

A documentation bug...my favorite kind.  Of course, you 
could always do the more malevolent fix, which would 
be to have XML_GetBuffer() return 0xd00d and 
XML_ParseBuffer() return error with message 'you 
blithering idiot, you can't do that!'.  Of course, 
XML_Parse() would not be changed at all, so people who 
use it would automatically get the core dump for 
accessing memory at 0xd00d.

Then again, that probably only works for my users.  
Some people aren't so tolerant. ;)

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-13 01:09

Message:
Logged In: YES 
user_id=290026

Great!
I think you are right - we should add a note to those
functions about when *not* to call them.

I leave this bug report open, so that we don't forget.
I am sure once Fred gets annoyed by the open bug
report he will read this note. <g>

Karl

----------------------------------------------------------------------

Comment By: Ari Johnson (ari_j)
Date: 2002-07-13 01:03

Message:
Logged In: YES 
user_id=90811

That worked, thanks!  Maybe you should make a very 
blatant note of that in the reference for all of 
XML_GetBuffer(), XML_ParseBuffer(), and XML_Parse(), as 
well as any other functions that have that requirement.  
Thanks again for the help, and the great library.  It's 
saving me from the bloat. ;)

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-13 00:19

Message:
Logged In: YES 
user_id=290026

Without running your code, just by looking at it:

You are not supposed to call XML_GetBuffer or 
XML_ParseBuffer from within a handler 
(xml_handle_endelement in your case).

Take it out and then try again.
I have a suspicion that that might help.

Karl



----------------------------------------------------------------------

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:39

Message:
Logged In: YES 
user_id=90811

No, my file size is not a multiple of 1024.  Also, as my 
file's name implies and you probably guessed from the 
jabber.xml file I'm using for testing, I intend to use this 
code over a network to communicate with a Jabber 
server.  So I absolutely can't predict my file size in 
advance.  However, I see the oversight you're pointing 
out and will correct it; that's not where this bug is 
coming from, though.

----------------------------------------------------------------------

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:34

Message:
Logged In: YES 
user_id=90811

Forgot about my platform-specific code...in test.c, 
change 'stdin->_file' to '0' and 'stdout->_file' to '1'.  
And to run it, ./test < jabber.xml > output.xml


----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 17:31

Message:
Logged In: YES 
user_id=290026

Another thought:

If your file size is a multiple of 1024, your code will
call XML_ParseBuffer twice with a buffer size of zero.

This is probably not what is was intended for.
If your file size happens to be like that, maybe you
could try another approach?

----------------------------------------------------------------------

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:28

Message:
Logged In: YES 
user_id=90811

I've narrowed the problem down considerably...

I had XML_ParseBuffer() print out 'start' to stderr after it 
sets start in the first bit of the function.  What I found is 
that the contents are correct, for example if I set my 
buffer to equal "<!-- this is a comment -->", then that 
string gets appended to the end of the buffer where it 
should be.  However, start still points to the beginning 
of the previous segment of the buffered text.  This is 
only apparently happening on the call to 
XML_ParseBuffer() after the call that doesn't use the full 
size of the buffer.

Attached, please find a .tar.gz (warning, no directory 
structure, but only 4 files so it shouldn't cause a mess 
for you) with the actual code I'm using.  You'll have to 
compile test.c and xmlstream.c manually and then link 
them to form an executable.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 17:15

Message:
Logged In: YES 
user_id=290026

Since I cannot duplicate this, do you have access
to another platform/OS and can you try it there?
Maybe it is related to the fact that you are compiling
and running this on your version of FreeBSD.



----------------------------------------------------------------------

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 17:04

Message:
Logged In: YES 
user_id=90811

It doesn't matter what size buffer I request, the 
XML_ParseBuffer() call ends up re-parsing the previous 
buffer when I give it a zero size argument.  Also, even if 
I feed it a fictitious XML comment, it still gives me the 
error 9 - junk after document element.

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 16:37

Message:
Logged In: YES 
user_id=290026

Try removing the call for getting a zero sized buffer:
  char *buff = XML_GetBuffer(p, 0);
or change the size parameter back to 1024.
Does that have any effect?


----------------------------------------------------------------------

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:29

Message:
Logged In: YES 
user_id=90811

Just an update...the same thing happens when I don't 
set isFinal in the error-producing call, or of course if I 
feed it more text (since this is just after the </root> tag 
has been read).

----------------------------------------------------------------------

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 16:10

Message:
Logged In: YES 
user_id=90811

I apologize for a mistake; the error it returns is 9 -> 
junk after document element.  I was calling 
GetErrorCode wrong.  Anyhow...

---
int c = 1024;
while(c == 1024) {
  char *buff = XML_GetBuffer(p, 1024);
  if(!buff)
    ...
  c = read(fd, buff, 1024);
  if(c < 0)
    ...
  if(!XML_ParseBuffer(p, c, 0))
    ...
}

...

void handle_end_element(...) {
  if([it was the root element]) {
    char *buff = XML_GetBuffer(p, 0);
    if(!XML_ParseBuffer(p, 0, 1))
      /* This is where the error occurs. */
  }
}


----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 15:42

Message:
Logged In: YES 
user_id=290026

In that case please post a small example that can
produce the behaviour you have reported.

Karl

----------------------------------------------------------------------

Comment By: Ari Johnson (ari_j)
Date: 2002-07-12 15:22

Message:
Logged In: YES 
user_id=90811

Same thing occurs with the current CVS.  This even 
occurs when I actually send XML_Parse*() some text to 
process.  And to make things worse, XML_Parse() 
returns false since it's trying to parse text past the close 
tag of my root element, but the error code is set to 0.


----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 09:07

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-12 08:52

Message:
Logged In: YES 
user_id=290026

Please retest with 1.95.3 or the current CVS.
Also, we are planning to release 1.95.4 today,
so if this is a bug, let's find out ASAP.

Karl

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=580503&group_id=10127


From noreply@sourceforge.net  Sat Jul 27 21:05:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat Jul 27 20:05:05 2002
Subject: [ expat-Bugs-544682 ] Support Pull operation
Message-ID: <E17YeMS-0004xf-00@usw-sf-web2.sourceforge.net>

Bugs item #544682, was opened at 2002-04-16 10:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=544682&group_id=10127

Category: None
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Karl Waclawek (kwaclaw)
>Assigned to: Karl Waclawek (kwaclaw)
Summary: Support Pull operation

Initial Comment:
Would it be hard to add the following functions?
 - suspend() ...suspends parsing, remembers state
 - resume()  ...resumes parsing from where it was 
suspended
 - abort()   ...cancels parsing
 
This looks like the concept of coroutines, and could 
have the following benefit: One could implement a
"pull" based  parser on top of the "push" based model 
of Expat.
 
This has recently been chosen as Microsoft's new 
approach,  i.e. in XML.NET, SAX has been replaced by
a pull based parser("XMLReader").
 
Typical pull code would look like:
 while parser.nextNode() do
 begin
  //process current node
 end;
 
It seems to me such a parser could be implemented on
top of SAX or Expat, if there was functionality as 
described above. Microsoft's MSXML3 implementation
has the IMXReaderControl interface, which allows 
exactly that. Makes me think that (maybe) MS's "pull"
implementation is implemented on top of their own SAX 
parser.
 
So, my question again: How hard would it be to add
such coroutine-like functionality to Expat?
 
Karl
 


----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-27 23:04

Message:
Logged In: YES 
user_id=290026

It looks as if I am going to try to port the block/unblock
functionality from the Mozilla version of Expat.
Assigned to me because of that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=544682&group_id=10127


From noreply@sourceforge.net  Sun Jul 28 19:07:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun Jul 28 18:07:02 2002
Subject: [ expat-Bugs-434664 ] utf8_toutf16 infinite loop
Message-ID: <E17Yyzw-0006Y4-00@usw-sf-web1.sourceforge.net>

Bugs item #434664, was opened at 2001-06-19 22:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=434664&group_id=10127

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 4
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: utf8_toutf16 infinite loop

Initial Comment:
I believe this is a low priority bug since I can't see 
how it could ever get tickled calling only the 
interface in expat.h, but I came across it while 
calling into xmltok directly. If the input buffer 
contains a BT_LEAD4 character with only space left for 
one output character, the routine goes into an 
infinite loop. I fixed it with the following goto --- 
your tolerance of goto may vary.

Michael Isard.

[ I am waiting for sourceforge to fix their new 
account procedure which seems to have been broken for 
some days --- in the meantime you can mail me directly 
at michael.isard@compaq.com ]

--------

from expat/xmltok/xmltok.c

static
void utf8_toUtf16(const ENCODING *enc,
		  const char **fromP, const char 
*fromLim,
		  unsigned short **toP, const unsigned 
short *toLim)
{
  unsigned short *to = *toP;
  const char *from = *fromP;
  while (from != fromLim && to != toLim) {
    switch (((struct normal_encoding *)enc)->type
[(unsigned char)*from]) {
    case BT_LEAD2:
      *to++ = ((from[0] & 0x1f) << 6) | (from[1] & 
0x3f);
      from += 2;
      break;
    case BT_LEAD3:
      *to++ = ((from[0] & 0xf) << 12) | ((from[1] & 
0x3f) << 6) | (from[2] & 0x3f);
      from += 3;
      break;
    case BT_LEAD4:
      {
	unsigned long n;
	if (to + 1 == toLim)
	  goto after; /* BUGBUG this used to say 
break; which keeps
                               looping */

	n = ((from[0] & 0x7) << 18) | ((from[1] & 
0x3f) << 12) | ((from[2] & 0x3f) << 6) | (from[3] & 
0x3f);
	n -= 0x10000;
	to[0] = (unsigned short)((n >> 10) | 0xD800);
	to[1] = (unsigned short)((n & 0x3FF) | 0xDC00);
	to += 2;
	from += 4;
      }
      break;
    default:
      *to++ = *from++;
      break;
    }
  }
 after: /* BUGBUG new jump target added to escape from 
loop */

  *fromP = from;
  *toP = to;
}


----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-28 21:06

Message:
Logged In: YES 
user_id=290026

Finally applied the patch.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-09 14:20

Message:
Logged In: YES 
user_id=3066

This is not XML::Parser specific, so I'm changing the
categorization.  Forcing SF to send me a copy of the
properly-indented code is a nice side-effect.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=434664&group_id=10127


From noreply@sourceforge.net  Wed Jul 31 09:41:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed Jul 31 08:41:02 2002
Subject: [ expat-Bugs-564275 ] Test 11 in stream.t fails
Message-ID: <E17Zva7-000252-00@usw-sf-web5.sourceforge.net>

Bugs item #564275, was opened at 2002-06-04 05:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=564275&group_id=10127

Category: XML::Parser (inactive)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Test 11 in stream.t fails

Initial Comment:
System: Linux 2.4.10-4GB i686
Expat-Version: 1.95.3
Perl-Version: 5.6.1

in stream.t, problem with encoding:

$string differs from $expected at index 333:
$string is result of parsing a document in
ISO-8859-1 encoding, input contains character
chr(160) which sneaks into output (UTF-8 encoding)
unchanged, instead of being converted to
chr(192)chr(160).


----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-07-31 11:40

Message:
Logged In: YES 
user_id=290026

Fred to follow up.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-21 10:14

Message:
Logged In: YES 
user_id=3066

This report can't be assigned to Clark Cooper since he's no
longer active on this project.  I'll see if I can round up
someone to help respond to XML::Parser issue reports -- I
don't know that anyone currently on this project knows much
about the Perl bindings.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-07 02:13

Message:
Logged In: NO 

Sorry, was a typo indeed.

After parsing the test string (in stream.t) following
expressions evaluate to true:

ord( substr($string,   332, 1) ) == 160;
ord( substr($expected, 332, 1) ) == 194;
ord( substr($expected, 333, 1) ) == 160;

The test failed yesterday on my freshly installed Suse 8.0
System at home, the expat-library was compiled on Suse 7.3
here at work, though. Some ideas, what's responsible for
this test failing? Thank you.



----------------------------------------------------------------------

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-06-06 13:59

Message:
Logged In: YES 
user_id=290026

Works for me.
Expat 1.95.3 returns 0xC2 0xA0
which corresponds to chr(194) chr(160).

I assume you made a typo, since chr(192) = 0xC0
is not valid for the first byte in a UTF-8 sequence.

Karl

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=564275&group_id=10127