From Michal.Roskanuk at merlin.cz  Thu Jan  2 19:32:27 2003
From: Michal.Roskanuk at merlin.cz (Roskanuk Michal)
Date: Thu Jan  2 13:33:00 2003
Subject: [Expat-bugs] Linefeed as part of chardata
Message-ID: <E50028F23FC6D3118B7D00609761083F023D81FB@MERKUR>

Hi,
I work on some parser, which needs to handle LF's as part of tag value,
but expat (1.95.5 win32) returns LF only if it's a first character AND
strips the rest. When LF is in the middle of contents, then it's taken
as end of chardata block. As i understand the XML specification LF is
legal part of chardata (see 2.2) or am i wrong?

Mike
 

From fdrake at acm.org  Thu Jan  2 13:39:51 2003
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Thu Jan  2 13:40:20 2003
Subject: [Expat-bugs] Linefeed as part of chardata
In-Reply-To: <E50028F23FC6D3118B7D00609761083F023D81FB@MERKUR>
References: <E50028F23FC6D3118B7D00609761083F023D81FB@MERKUR>
Message-ID: <15892.34679.937022.146@grendel.zope.com>


Roskanuk Michal writes:
 > I work on some parser, which needs to handle LF's as part of tag value,
 > but expat (1.95.5 win32) returns LF only if it's a first character AND
 > strips the rest. When LF is in the middle of contents, then it's taken
 > as end of chardata block. As i understand the XML specification LF is
 > legal part of chardata (see 2.2) or am i wrong?

This sounds like you're not collecting character data but trying to
handle complete content in the handler.  That won't work; the handler
is called several times for stretches of PCDATA that include newlines;
you'll need to collect each 'chunk' and then process it once you have
it all.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation

From noreply at sourceforge.net  Thu Jan  2 19:43:58 2003
From: noreply at sourceforge.net (noreply@sourceforge.net)
Date: Thu Jan  2 22:43:23 2003
Subject: [Expat-bugs] [ expat-Bugs-661447 ] problem compiling XML::Parser
Message-ID: <E18UIkY-0002OB-00@sc8-sf-web4.sourceforge.net>

Bugs item #661447, was opened at 2003-01-02 19:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=661447&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: problem compiling XML::Parser

Initial Comment:
I attempted to install XML::Parser on a machine running
Solaris 8 with GCC 2.95.3

It failed due to a dependancy on Expat, so I
downloaded, compiled and installed expat-1.95.5

The next time i attempted to install XML::Parser I got
this:

bash#   perl Makefile.PL EXPATLIBPATH=/opt/lib
EXPATINCPATH=/opt/include
Checking if your kit is complete...
Looks good
Writing Makefile for XML::Parser::Expat
Writing Makefile for XML::Parser
bash# make
cp Parser/Encodings/README
blib/lib/XML/Parser/Encodings/README
cp Parser/Encodings/x-sjis-cp932.enc
blib/lib/XML/Parser/Encodings/x-sjis-cp932.enc
cp Parser/Encodings/iso-8859-7.enc
blib/lib/XML/Parser/Encodings/iso-8859-7.enc
cp Parser/Encodings/big5.enc
blib/lib/XML/Parser/Encodings/big5.enc
cp Parser/Encodings/windows-1250.enc
blib/lib/XML/Parser/Encodings/windows-1250.enc
cp Parser/Encodings/iso-8859-8.enc
blib/lib/XML/Parser/Encodings/iso-8859-8.enc
cp Parser/Encodings/iso-8859-2.enc
blib/lib/XML/Parser/Encodings/iso-8859-2.enc
cp Parser/Encodings/x-euc-jp-jisx0221.enc
blib/lib/XML/Parser/Encodings/x-euc-jp-jisx0221.enc
cp Parser/Encodings/iso-8859-9.enc
blib/lib/XML/Parser/Encodings/iso-8859-9.enc
cp Parser/Encodings/x-sjis-unicode.enc
blib/lib/XML/Parser/Encodings/x-sjis-unicode.enc
cp Parser/Encodings/iso-8859-3.enc
blib/lib/XML/Parser/Encodings/iso-8859-3.enc
cp Parser/Encodings/x-sjis-jdk117.enc
blib/lib/XML/Parser/Encodings/x-sjis-jdk117.enc
cp Parser/Encodings/euc-kr.enc
blib/lib/XML/Parser/Encodings/euc-kr.enc
cp Parser/Encodings/iso-8859-4.enc
blib/lib/XML/Parser/Encodings/iso-8859-4.enc
cp Parser/Encodings/Japanese_Encodings.msg
blib/lib/XML/Parser/Encodings/Japanese_Encodings.msg
cp Parser/Encodings/x-sjis-jisx0221.enc
blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc
cp Parser.pm blib/lib/XML/Parser.pm
cp Parser/Encodings/iso-8859-5.enc
blib/lib/XML/Parser/Encodings/iso-8859-5.enc
cp Parser/Encodings/x-euc-jp-unicode.enc
blib/lib/XML/Parser/Encodings/x-euc-jp-unicode.enc
cp Parser/LWPExternEnt.pl
blib/lib/XML/Parser/LWPExternEnt.pl
make[1]: Entering directory
`/var/.cpan/build/XML-Parser-2.31/Expat'
cp Expat.pm ../blib/lib/XML/Parser/Expat.pm
/opt/bin/perl -I/opt/lib/perl5/5.6.1/sun4-solaris
-I/opt/lib/perl5/5.6.1
/opt/lib/perl5/5.6.1/ExtUtils/xsubpp -noprototypes
-typemap /opt/lib/perl5/5.6.1/ExtUtils/typemap -typemap
typemap Expat.xs > Expat.xsc && mv Expat.xsc Expat.c
/opt/bin/gcc -c -I/opt/include -fno-strict-aliasing
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O  
-DVERSION=\2.31\ -DXS_VERSION=\2.31\ -fPIC
-I/opt/lib/perl5/5.6.1/sun4-solaris/CORE  Expat.c
Expat.xs:140: warning: `ERRSV' redefined
/opt/lib/perl5/5.6.1/sun4-solaris/CORE/perl.h:768:
warning: this is the location of the previous definition
Expat.xs:132: conflicting types for `Perl_newSVpvn'
/opt/lib/perl5/5.6.1/sun4-solaris/CORE/proto.h:551:
previous declaration of `Perl_newSVpvn'
Expat.xs: In function `nsStart':
Expat.xs:678: `sv_undef' undeclared (first use in this
function)
Expat.xs:678: (Each undeclared identifier is reported
only once
Expat.xs:678: for each function it appears in.)
Expat.xs: In function `nsEnd':
Expat.xs:698: `sv_undef' undeclared (first use in this
function)
Expat.xs: In function `attributeDecl':
Expat.xs:783: `sv_yes' undeclared (first use in this
function)
Expat.xs: In function `entityDecl':
Expat.xs:811: `sv_undef' undeclared (first use in this
function)
Expat.xs:816: `sv_yes' undeclared (first use in this
function)
Expat.xs: In function `doctypeStart':
Expat.xs:840: `sv_undef' undeclared (first use in this
function)
Expat.xs:842: `sv_yes' undeclared (first use in this
function)
Expat.xs:842: `sv_no' undeclared (first use in this
function)

I was eventually able to solve the problem by removing the
"/opt/include/patchlevel.h" file, after which
XML::Parser compiled smoothly. I am just posting this
bug so you will be aware of this problem.

Tristan Lawrence
Globix Corporation
www.globix.com

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

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

From noreply at sourceforge.net  Fri Jan  3 07:50:10 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan  3 11:03:34 2003
Subject: [Expat-bugs] [ expat-Bugs-661447 ] problem compiling XML::Parser
Message-ID: <E18UU5K-0001Bk-00@sc8-sf-web3.sourceforge.net>

Bugs item #661447, was opened at 2003-01-02 22:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=661447&group_id=10127

>Category: XML::Parser (inactive)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: problem compiling XML::Parser

Initial Comment:
I attempted to install XML::Parser on a machine running
Solaris 8 with GCC 2.95.3

It failed due to a dependancy on Expat, so I
downloaded, compiled and installed expat-1.95.5

The next time i attempted to install XML::Parser I got
this:

bash#   perl Makefile.PL EXPATLIBPATH=/opt/lib
EXPATINCPATH=/opt/include
Checking if your kit is complete...
Looks good
Writing Makefile for XML::Parser::Expat
Writing Makefile for XML::Parser
bash# make
cp Parser/Encodings/README
blib/lib/XML/Parser/Encodings/README
cp Parser/Encodings/x-sjis-cp932.enc
blib/lib/XML/Parser/Encodings/x-sjis-cp932.enc
cp Parser/Encodings/iso-8859-7.enc
blib/lib/XML/Parser/Encodings/iso-8859-7.enc
cp Parser/Encodings/big5.enc
blib/lib/XML/Parser/Encodings/big5.enc
cp Parser/Encodings/windows-1250.enc
blib/lib/XML/Parser/Encodings/windows-1250.enc
cp Parser/Encodings/iso-8859-8.enc
blib/lib/XML/Parser/Encodings/iso-8859-8.enc
cp Parser/Encodings/iso-8859-2.enc
blib/lib/XML/Parser/Encodings/iso-8859-2.enc
cp Parser/Encodings/x-euc-jp-jisx0221.enc
blib/lib/XML/Parser/Encodings/x-euc-jp-jisx0221.enc
cp Parser/Encodings/iso-8859-9.enc
blib/lib/XML/Parser/Encodings/iso-8859-9.enc
cp Parser/Encodings/x-sjis-unicode.enc
blib/lib/XML/Parser/Encodings/x-sjis-unicode.enc
cp Parser/Encodings/iso-8859-3.enc
blib/lib/XML/Parser/Encodings/iso-8859-3.enc
cp Parser/Encodings/x-sjis-jdk117.enc
blib/lib/XML/Parser/Encodings/x-sjis-jdk117.enc
cp Parser/Encodings/euc-kr.enc
blib/lib/XML/Parser/Encodings/euc-kr.enc
cp Parser/Encodings/iso-8859-4.enc
blib/lib/XML/Parser/Encodings/iso-8859-4.enc
cp Parser/Encodings/Japanese_Encodings.msg
blib/lib/XML/Parser/Encodings/Japanese_Encodings.msg
cp Parser/Encodings/x-sjis-jisx0221.enc
blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc
cp Parser.pm blib/lib/XML/Parser.pm
cp Parser/Encodings/iso-8859-5.enc
blib/lib/XML/Parser/Encodings/iso-8859-5.enc
cp Parser/Encodings/x-euc-jp-unicode.enc
blib/lib/XML/Parser/Encodings/x-euc-jp-unicode.enc
cp Parser/LWPExternEnt.pl
blib/lib/XML/Parser/LWPExternEnt.pl
make[1]: Entering directory
`/var/.cpan/build/XML-Parser-2.31/Expat'
cp Expat.pm ../blib/lib/XML/Parser/Expat.pm
/opt/bin/perl -I/opt/lib/perl5/5.6.1/sun4-solaris
-I/opt/lib/perl5/5.6.1
/opt/lib/perl5/5.6.1/ExtUtils/xsubpp -noprototypes
-typemap /opt/lib/perl5/5.6.1/ExtUtils/typemap -typemap
typemap Expat.xs > Expat.xsc && mv Expat.xsc Expat.c
/opt/bin/gcc -c -I/opt/include -fno-strict-aliasing
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O  
-DVERSION=\2.31\ -DXS_VERSION=\2.31\ -fPIC
-I/opt/lib/perl5/5.6.1/sun4-solaris/CORE  Expat.c
Expat.xs:140: warning: `ERRSV' redefined
/opt/lib/perl5/5.6.1/sun4-solaris/CORE/perl.h:768:
warning: this is the location of the previous definition
Expat.xs:132: conflicting types for `Perl_newSVpvn'
/opt/lib/perl5/5.6.1/sun4-solaris/CORE/proto.h:551:
previous declaration of `Perl_newSVpvn'
Expat.xs: In function `nsStart':
Expat.xs:678: `sv_undef' undeclared (first use in this
function)
Expat.xs:678: (Each undeclared identifier is reported
only once
Expat.xs:678: for each function it appears in.)
Expat.xs: In function `nsEnd':
Expat.xs:698: `sv_undef' undeclared (first use in this
function)
Expat.xs: In function `attributeDecl':
Expat.xs:783: `sv_yes' undeclared (first use in this
function)
Expat.xs: In function `entityDecl':
Expat.xs:811: `sv_undef' undeclared (first use in this
function)
Expat.xs:816: `sv_yes' undeclared (first use in this
function)
Expat.xs: In function `doctypeStart':
Expat.xs:840: `sv_undef' undeclared (first use in this
function)
Expat.xs:842: `sv_yes' undeclared (first use in this
function)
Expat.xs:842: `sv_no' undeclared (first use in this
function)

I was eventually able to solve the problem by removing the
"/opt/include/patchlevel.h" file, after which
XML::Parser compiled smoothly. I am just posting this
bug so you will be aware of this problem.

Tristan Lawrence
Globix Corporation
www.globix.com

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-03 10:50

Message:
Logged In: YES 
user_id=290026

Thank you for your bug report.
Unfortunately there is currently no one on our team
experienced with XML::Parser. 

You may want to report this where XML::Parser
is maintained. Not sure if this is still active:

http://rt.cpan.org/NoAuth/Bugs.html?Dist=XML-Parser

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

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

From noreply at sourceforge.net  Fri Jan  3 11:18:37 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan  3 14:17:55 2003
Subject: [Expat-bugs] [ expat-Bugs-661447 ] problem compiling XML::Parser
Message-ID: <E18UXL3-0002c5-00@sc8-sf-web3.sourceforge.net>

Bugs item #661447, was opened at 2003-01-02 19:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=661447&group_id=10127

Category: XML::Parser (inactive)
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: problem compiling XML::Parser

Initial Comment:
I attempted to install XML::Parser on a machine running
Solaris 8 with GCC 2.95.3

It failed due to a dependancy on Expat, so I
downloaded, compiled and installed expat-1.95.5

The next time i attempted to install XML::Parser I got
this:

bash#   perl Makefile.PL EXPATLIBPATH=/opt/lib
EXPATINCPATH=/opt/include
Checking if your kit is complete...
Looks good
Writing Makefile for XML::Parser::Expat
Writing Makefile for XML::Parser
bash# make
cp Parser/Encodings/README
blib/lib/XML/Parser/Encodings/README
cp Parser/Encodings/x-sjis-cp932.enc
blib/lib/XML/Parser/Encodings/x-sjis-cp932.enc
cp Parser/Encodings/iso-8859-7.enc
blib/lib/XML/Parser/Encodings/iso-8859-7.enc
cp Parser/Encodings/big5.enc
blib/lib/XML/Parser/Encodings/big5.enc
cp Parser/Encodings/windows-1250.enc
blib/lib/XML/Parser/Encodings/windows-1250.enc
cp Parser/Encodings/iso-8859-8.enc
blib/lib/XML/Parser/Encodings/iso-8859-8.enc
cp Parser/Encodings/iso-8859-2.enc
blib/lib/XML/Parser/Encodings/iso-8859-2.enc
cp Parser/Encodings/x-euc-jp-jisx0221.enc
blib/lib/XML/Parser/Encodings/x-euc-jp-jisx0221.enc
cp Parser/Encodings/iso-8859-9.enc
blib/lib/XML/Parser/Encodings/iso-8859-9.enc
cp Parser/Encodings/x-sjis-unicode.enc
blib/lib/XML/Parser/Encodings/x-sjis-unicode.enc
cp Parser/Encodings/iso-8859-3.enc
blib/lib/XML/Parser/Encodings/iso-8859-3.enc
cp Parser/Encodings/x-sjis-jdk117.enc
blib/lib/XML/Parser/Encodings/x-sjis-jdk117.enc
cp Parser/Encodings/euc-kr.enc
blib/lib/XML/Parser/Encodings/euc-kr.enc
cp Parser/Encodings/iso-8859-4.enc
blib/lib/XML/Parser/Encodings/iso-8859-4.enc
cp Parser/Encodings/Japanese_Encodings.msg
blib/lib/XML/Parser/Encodings/Japanese_Encodings.msg
cp Parser/Encodings/x-sjis-jisx0221.enc
blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc
cp Parser.pm blib/lib/XML/Parser.pm
cp Parser/Encodings/iso-8859-5.enc
blib/lib/XML/Parser/Encodings/iso-8859-5.enc
cp Parser/Encodings/x-euc-jp-unicode.enc
blib/lib/XML/Parser/Encodings/x-euc-jp-unicode.enc
cp Parser/LWPExternEnt.pl
blib/lib/XML/Parser/LWPExternEnt.pl
make[1]: Entering directory
`/var/.cpan/build/XML-Parser-2.31/Expat'
cp Expat.pm ../blib/lib/XML/Parser/Expat.pm
/opt/bin/perl -I/opt/lib/perl5/5.6.1/sun4-solaris
-I/opt/lib/perl5/5.6.1
/opt/lib/perl5/5.6.1/ExtUtils/xsubpp -noprototypes
-typemap /opt/lib/perl5/5.6.1/ExtUtils/typemap -typemap
typemap Expat.xs > Expat.xsc && mv Expat.xsc Expat.c
/opt/bin/gcc -c -I/opt/include -fno-strict-aliasing
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O  
-DVERSION=\2.31\ -DXS_VERSION=\2.31\ -fPIC
-I/opt/lib/perl5/5.6.1/sun4-solaris/CORE  Expat.c
Expat.xs:140: warning: `ERRSV' redefined
/opt/lib/perl5/5.6.1/sun4-solaris/CORE/perl.h:768:
warning: this is the location of the previous definition
Expat.xs:132: conflicting types for `Perl_newSVpvn'
/opt/lib/perl5/5.6.1/sun4-solaris/CORE/proto.h:551:
previous declaration of `Perl_newSVpvn'
Expat.xs: In function `nsStart':
Expat.xs:678: `sv_undef' undeclared (first use in this
function)
Expat.xs:678: (Each undeclared identifier is reported
only once
Expat.xs:678: for each function it appears in.)
Expat.xs: In function `nsEnd':
Expat.xs:698: `sv_undef' undeclared (first use in this
function)
Expat.xs: In function `attributeDecl':
Expat.xs:783: `sv_yes' undeclared (first use in this
function)
Expat.xs: In function `entityDecl':
Expat.xs:811: `sv_undef' undeclared (first use in this
function)
Expat.xs:816: `sv_yes' undeclared (first use in this
function)
Expat.xs: In function `doctypeStart':
Expat.xs:840: `sv_undef' undeclared (first use in this
function)
Expat.xs:842: `sv_yes' undeclared (first use in this
function)
Expat.xs:842: `sv_no' undeclared (first use in this
function)

I was eventually able to solve the problem by removing the
"/opt/include/patchlevel.h" file, after which
XML::Parser compiled smoothly. I am just posting this
bug so you will be aware of this problem.

Tristan Lawrence
Globix Corporation
www.globix.com

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

>Comment By: Greg Stein (gstein)
Date: 2003-01-03 11:18

Message:
Logged In: YES 
user_id=6501

Since this isn't Expat and patchlevel.h is not part of
Expat, I'm closing this bug as "invalid".

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-03 07:50

Message:
Logged In: YES 
user_id=290026

Thank you for your bug report.
Unfortunately there is currently no one on our team
experienced with XML::Parser. 

You may want to report this where XML::Parser
is maintained. Not sure if this is still active:

http://rt.cpan.org/NoAuth/Bugs.html?Dist=XML-Parser

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

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

From noreply at sourceforge.net  Fri Jan  3 11:20:06 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan  3 14:19:25 2003
Subject: [Expat-bugs] [ expat-Bugs-601978 ] xmlwf should link statically to
	Expat
Message-ID: <E18UXMU-0002i6-00@sc8-sf-web3.sourceforge.net>

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

Category: Build control
Group: Feature Request
Status: Open
Resolution: None
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Greg Stein (gstein)
Summary: xmlwf should link statically to Expat

Initial Comment:
I'm sure there's a way to link the Expat library into
the executables built from the Expat distribution, but
I'm not sure what the portable "libtool way" is.

I can do this on Linux by building xmlwf using "make
LDFLAGS=-static", but doubt this will work cross-platform.

Can you add the right magic to the LINK_EXE variable in
Makefile.in?  Thanks!

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

>Comment By: Greg Stein (gstein)
Date: 2003-01-03 11:20

Message:
Logged In: YES 
user_id=6501

Yes, there is a libtool switch to do this, but I'm not sure
why. Why wouldn't we just link to the shared library?


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

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

Message:
Logged In: YES 
user_id=290026

I am not sure I should mention this here:

But there is another issue still open, as listed
in the requirements for the next release:

The build process on Unix should create both
libexpat.{a,so} and libexpatw.{a,so} by default.



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

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

From noreply at sourceforge.net  Fri Jan  3 11:22:25 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan  3 14:21:41 2003
Subject: [Expat-bugs] [ expat-Bugs-566088 ] php make fails @ libexpat.la on
	OSX
Message-ID: <E18UXOj-0002ph-00@sc8-sf-web3.sourceforge.net>

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

Category: Build control
Group: Third-party Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: php make fails @ libexpat.la on OSX

Initial Comment:
hi all,

a build of php-latest (php4-200206071800) on OSX Server
10.1.4 with:

./configure --enable-shared --enable-static
--prefix=/usr/local/php4 --with-layout=PHP
--with-apxs2=/usr/local/apache2/sbin/apxs
--with-config-file-path=/private/etc/php4/
--mandir=/usr/local/man
--localstatedir=/private/var/php4
--x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib
--with-expat-dir=/usr/local/expat
--with-mysql=/usr/local/mysql --with-openssl
--with-imap-ssl --with-mcrypt --with-mhash=/usr/local
--with-kerberos --with-imap=/usr/local/imap
--enable-mailparse --enable-magic-quotes --enable-ftp
--enable-force-cgi-redirect --enable-discard-path
--enable-inline-optimization --with-pear --with-zlib
--enable-calendar --disable-safe-mode --with-tsrm-pthreads

fails with:

.o Zend/zend_qsort.o Zend/zend_multibyte.o
Zend/zend_execute.o sapi/apache2filter/sapi_apache2.o
sapi/apache2filter/apache_config.o
sapi/apache2filter/php_functions.o
main/internal_functions.o -lcrypto -lssl -lc-client
-lexpat -lmysqlclient -lmhash -lmcrypt -lltdl -lz -lssl
-lcrypto -lbind -lm -ldl -lgssapi_krb5 -lkrb5
-lk5crypto -lcom_err -ldl -o libs/libphp4.bundle && cp
libs/libphp4.bundle libs/libphp4.so
/usr/bin/ld: warning -L: directory name (/lib) does not
exist
/usr/bin/ld: /usr/local/expat/lib/libexpat.la bad magic
number (not a Mach-O file)
make: *** [libs/libphp4.bundle] Error 1

expat build went fine on OSX, with:

cd expat-1.95.3;
./configure --prefix=/usr/local/expat
--mandir=/usr/local/man --x-include=/usr

to be used by a number of other progrs successfully ......

any thoughts/suggestions on either would be much
appreciated!

fyi, details of my environment are doc'd on my
web-page, below .....

thanks!

richard


--------------------------------------
R Blake
blakers <at> mac.com
http://homepage.mac.com/blakers
--------------------------------------

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

>Comment By: Greg Stein (gstein)
Date: 2003-01-03 11:22

Message:
Logged In: YES 
user_id=6501

This may be caused by an old version of libtool being used
to create the tarball. Please try rebuilding the libtool
scripts by running the "buildconf.sh" script found in the
top-level dir of the distribution. Make sure that your OSX
box has the "correct" libtool. (I'm not sure where that can
be found, but I do know that libtool has had problems on OSX)

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

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

From noreply at sourceforge.net  Wed Jan  8 10:40:44 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jan  8 13:39:15 2003
Subject: [Expat-bugs] [ expat-Bugs-664541 ] check.h should be tested by
	configure
Message-ID: <E18WL88-0006TF-00@sc8-sf-web1.sourceforge.net>

Bugs item #664541, was opened at 2003-01-08 18:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=664541&group_id=10127

Category: Build control
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ed Avis (epaepa)
Assigned to: Greg Stein (gstein)
Summary: check.h should be tested by configure

Initial Comment:
The presence of the check library (and check.h) should
be checked by 'configure', and if it's not there then
'make check' should print a warning.  Otherwise you get
some rather alarming errors seeming to come from the
test suite :-(.

(expat-1.95.5)

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

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

From noreply at sourceforge.net  Wed Jan  8 16:20:44 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jan  8 19:19:22 2003
Subject: [Expat-bugs] [ expat-Bugs-664541 ] check.h should be tested by
	configure
Message-ID: <E18WQRA-0003Kj-00@sc8-sf-web2.sourceforge.net>

Bugs item #664541, was opened at 2003-01-08 10:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=664541&group_id=10127

Category: Build control
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ed Avis (epaepa)
Assigned to: Greg Stein (gstein)
Summary: check.h should be tested by configure

Initial Comment:
The presence of the check library (and check.h) should
be checked by 'configure', and if it's not there then
'make check' should print a warning.  Otherwise you get
some rather alarming errors seeming to come from the
test suite :-(.

(expat-1.95.5)

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

>Comment By: Greg Stein (gstein)
Date: 2003-01-08 16:20

Message:
Logged In: YES 
user_id=6501

Good idea. This shouldn't be too hard at all. Thx.

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

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

From noreply at sourceforge.net  Mon Jan 13 17:49:30 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jan 13 20:47:04 2003
Subject: [Expat-bugs] [ expat-Bugs-667511 ] additional patch for #618199
Message-ID: <E18YGCo-0001gq-00@sc8-sf-web3.sourceforge.net>

Bugs item #667511, was opened at 2003-01-13 18:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=667511&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Nobody/Anonymous (nobody)
Summary: additional patch for #618199

Initial Comment:
The attached patch ensures that localPart will point to TAG.buf 
when storeRawNames is called. 
 
There was no need to replace the TAG_NAME.str with the 
keyname for the ELEMENT_TYPE hash entry since the pool 
takes care of deallocating it (keyname) when the pool is 
destroyed. 

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

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

From noreply at sourceforge.net  Mon Jan 13 18:06:26 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jan 13 21:04:09 2003
Subject: [Expat-bugs] [ expat-Bugs-667511 ] additional patch for #618199
Message-ID: <E18YGTC-0008JN-00@sc8-sf-web1.sourceforge.net>

Bugs item #667511, was opened at 2003-01-13 20:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=667511&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Kloth (jkloth)
>Assigned to: Karl Waclawek (kwaclaw)
Summary: additional patch for #618199

Initial Comment:
The attached patch ensures that localPart will point to TAG.buf 
when storeRawNames is called. 
 
There was no need to replace the TAG_NAME.str with the 
keyname for the ELEMENT_TYPE hash entry since the pool 
takes care of deallocating it (keyname) when the pool is 
destroyed. 

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-13 21:06

Message:
Logged In: YES 
user_id=290026

Two things:

- I can't see the attachment
- Does this apply to the current CVS?

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

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

From noreply at sourceforge.net  Mon Jan 13 18:34:05 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jan 13 21:31:41 2003
Subject: [Expat-bugs] [ expat-Bugs-667511 ] additional patch for #618199
Message-ID: <E18YGtx-0002w5-00@sc8-sf-web3.sourceforge.net>

Bugs item #667511, was opened at 2003-01-13 18:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=667511&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Karl Waclawek (kwaclaw)
Summary: additional patch for #618199

Initial Comment:
The attached patch ensures that localPart will point to TAG.buf 
when storeRawNames is called. 
 
There was no need to replace the TAG_NAME.str with the 
keyname for the ELEMENT_TYPE hash entry since the pool 
takes care of deallocating it (keyname) when the pool is 
destroyed. 

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

>Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-13 19:34

Message:
Logged In: YES 
user_id=38980

Oops... 
Here is the attachment again 

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

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

Message:
Logged In: YES 
user_id=290026

Two things:

- I can't see the attachment
- Does this apply to the current CVS?

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

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

From noreply at sourceforge.net  Mon Jan 13 20:05:34 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jan 13 23:03:15 2003
Subject: [Expat-bugs] [ expat-Bugs-667511 ] additional patch for #618199
Message-ID: <E18YIKU-00035S-00@sc8-sf-web1.sourceforge.net>

Bugs item #667511, was opened at 2003-01-13 20:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=667511&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Karl Waclawek (kwaclaw)
Summary: additional patch for #618199

Initial Comment:
The attached patch ensures that localPart will point to TAG.buf 
when storeRawNames is called. 
 
There was no need to replace the TAG_NAME.str with the 
keyname for the ELEMENT_TYPE hash entry since the pool 
takes care of deallocating it (keyname) when the pool is 
destroyed. 

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-13 23:05

Message:
Logged In: YES 
user_id=290026

I think you meant to say:

"The attached patch ensures that TAG_NAME.str will point to
TAG.buf when storeRawNames is called."

Your changes make sense to me, but I am not sure
that there is a bug, since TAG_NAME.str doesn't need
to be updated when it does not point to tag->buf.

Is there a specific case where it fails for you?
If yes, would you please give us the details, so that
we can build a regression test for the patch?

Thanks! 




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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-13 21:34

Message:
Logged In: YES 
user_id=38980

Oops... 
Here is the attachment again 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-13 21:06

Message:
Logged In: YES 
user_id=290026

Two things:

- I can't see the attachment
- Does this apply to the current CVS?

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

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

From noreply at sourceforge.net  Tue Jan 14 01:16:37 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 14 04:14:22 2003
Subject: [Expat-bugs] [ expat-Bugs-667511 ] additional patch for #618199
Message-ID: <E18YNBV-0007jH-00@sc8-sf-web2.sourceforge.net>

Bugs item #667511, was opened at 2003-01-13 18:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=667511&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Karl Waclawek (kwaclaw)
Summary: additional patch for #618199

Initial Comment:
The attached patch ensures that localPart will point to TAG.buf 
when storeRawNames is called. 
 
There was no need to replace the TAG_NAME.str with the 
keyname for the ELEMENT_TYPE hash entry since the pool 
takes care of deallocating it (keyname) when the pool is 
destroyed. 

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

>Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-14 02:16

Message:
Logged In: YES 
user_id=38980

Sorry, I cannot trim a problem to a small test case.  It seems to 
require a certain amount of additional malloc/realloc/free that I 
cannot determine.  I can say that it only happens when doing multiple 
XML_ParseBuffer calls.  Eith debug prints I traced the error to where 
storeRawNames updates the TAG_NAME.localPart.   
 
The problem is that it should only be updated when localPart points 
into tag->buf, which it almost always does.  The exception to this is 
addressed by my patch.  To fix this in storeRawNames would add 
overhead that is not required if TAG_NAME.str is not redefined before 
TAG_NAME.localPart is defined in storeAtts. 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-13 21:05

Message:
Logged In: YES 
user_id=290026

I think you meant to say:

"The attached patch ensures that TAG_NAME.str will point to
TAG.buf when storeRawNames is called."

Your changes make sense to me, but I am not sure
that there is a bug, since TAG_NAME.str doesn't need
to be updated when it does not point to tag->buf.

Is there a specific case where it fails for you?
If yes, would you please give us the details, so that
we can build a regression test for the patch?

Thanks! 




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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-13 19:34

Message:
Logged In: YES 
user_id=38980

Oops... 
Here is the attachment again 

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

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

Message:
Logged In: YES 
user_id=290026

Two things:

- I can't see the attachment
- Does this apply to the current CVS?

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

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

From noreply at sourceforge.net  Tue Jan 14 09:48:15 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 14 12:45:50 2003
Subject: [Expat-bugs] [ expat-Bugs-667511 ] additional patch for #618199
Message-ID: <E18YVAd-00074s-00@sc8-sf-web4.sourceforge.net>

Bugs item #667511, was opened at 2003-01-13 20:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=667511&group_id=10127

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Karl Waclawek (kwaclaw)
Summary: additional patch for #618199

Initial Comment:
The attached patch ensures that localPart will point to TAG.buf 
when storeRawNames is called. 
 
There was no need to replace the TAG_NAME.str with the 
keyname for the ELEMENT_TYPE hash entry since the pool 
takes care of deallocating it (keyname) when the pool is 
destroyed. 

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-14 12:48

Message:
Logged In: YES 
user_id=290026

I looked at storeAtts, and I agree with your assessment.
tag->name.str is always pointing into tag->buf when 
passed to storeAtts() (except for empty elements, but 
for that storeRawnames won't get called).

tag->name.localPart is set to point to tag->name.str 
inside of  storeAtts(). So, if tag->name.str gets 
reassigned inside storeAtts() before assigning it to 
localPart then localPart will not point into tag->buf 
anymore.

I will apply your patch soon.


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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-14 04:16

Message:
Logged In: YES 
user_id=38980

Sorry, I cannot trim a problem to a small test case.  It seems to 
require a certain amount of additional malloc/realloc/free that I 
cannot determine.  I can say that it only happens when doing multiple 
XML_ParseBuffer calls.  Eith debug prints I traced the error to where 
storeRawNames updates the TAG_NAME.localPart.   
 
The problem is that it should only be updated when localPart points 
into tag->buf, which it almost always does.  The exception to this is 
addressed by my patch.  To fix this in storeRawNames would add 
overhead that is not required if TAG_NAME.str is not redefined before 
TAG_NAME.localPart is defined in storeAtts. 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-13 23:05

Message:
Logged In: YES 
user_id=290026

I think you meant to say:

"The attached patch ensures that TAG_NAME.str will point to
TAG.buf when storeRawNames is called."

Your changes make sense to me, but I am not sure
that there is a bug, since TAG_NAME.str doesn't need
to be updated when it does not point to tag->buf.

Is there a specific case where it fails for you?
If yes, would you please give us the details, so that
we can build a regression test for the patch?

Thanks! 




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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-13 21:34

Message:
Logged In: YES 
user_id=38980

Oops... 
Here is the attachment again 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-13 21:06

Message:
Logged In: YES 
user_id=290026

Two things:

- I can't see the attachment
- Does this apply to the current CVS?

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

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

From noreply at sourceforge.net  Tue Jan 14 16:57:29 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 14 19:55:02 2003
Subject: [Expat-bugs] [ expat-Bugs-667511 ] additional patch for #618199
Message-ID: <E18Ybs1-0000jp-00@sc8-sf-web4.sourceforge.net>

Bugs item #667511, was opened at 2003-01-13 20:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=667511&group_id=10127

Category: None
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Jeremy Kloth (jkloth)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: additional patch for #618199

Initial Comment:
The attached patch ensures that localPart will point to TAG.buf 
when storeRawNames is called. 
 
There was no need to replace the TAG_NAME.str with the 
keyname for the ELEMENT_TYPE hash entry since the pool 
takes care of deallocating it (keyname) when the pool is 
destroyed. 

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-14 19:57

Message:
Logged In: YES 
user_id=290026

Patch applied in rev. 1.101 of xmlparse.c.

Assigned to Fred for regression testing.
However, no reproducible bug description was supplied by
the author of this bug report.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-14 12:48

Message:
Logged In: YES 
user_id=290026

I looked at storeAtts, and I agree with your assessment.
tag->name.str is always pointing into tag->buf when 
passed to storeAtts() (except for empty elements, but 
for that storeRawnames won't get called).

tag->name.localPart is set to point to tag->name.str 
inside of  storeAtts(). So, if tag->name.str gets 
reassigned inside storeAtts() before assigning it to 
localPart then localPart will not point into tag->buf 
anymore.

I will apply your patch soon.


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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-14 04:16

Message:
Logged In: YES 
user_id=38980

Sorry, I cannot trim a problem to a small test case.  It seems to 
require a certain amount of additional malloc/realloc/free that I 
cannot determine.  I can say that it only happens when doing multiple 
XML_ParseBuffer calls.  Eith debug prints I traced the error to where 
storeRawNames updates the TAG_NAME.localPart.   
 
The problem is that it should only be updated when localPart points 
into tag->buf, which it almost always does.  The exception to this is 
addressed by my patch.  To fix this in storeRawNames would add 
overhead that is not required if TAG_NAME.str is not redefined before 
TAG_NAME.localPart is defined in storeAtts. 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-13 23:05

Message:
Logged In: YES 
user_id=290026

I think you meant to say:

"The attached patch ensures that TAG_NAME.str will point to
TAG.buf when storeRawNames is called."

Your changes make sense to me, but I am not sure
that there is a bug, since TAG_NAME.str doesn't need
to be updated when it does not point to tag->buf.

Is there a specific case where it fails for you?
If yes, would you please give us the details, so that
we can build a regression test for the patch?

Thanks! 




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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-13 21:34

Message:
Logged In: YES 
user_id=38980

Oops... 
Here is the attachment again 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-13 21:06

Message:
Logged In: YES 
user_id=290026

Two things:

- I can't see the attachment
- Does this apply to the current CVS?

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

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

From noreply at sourceforge.net  Thu Jan 16 14:15:29 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jan 16 17:12:50 2003
Subject: [Expat-bugs] 
 [ expat-Bugs-651754 ] Function to get XML_Memory_Handling_Suite
Message-ID: <E18ZIIL-0003nI-00@sc8-sf-web2.sourceforge.net>

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

Category: None
Group: Feature Request
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Artyom Bolgar (artyom17)
Assigned to: Nobody/Anonymous (nobody)
Summary: Function to get XML_Memory_Handling_Suite

Initial Comment:
It is not a bug report, it is a feature request. What do 
you think of adding the function, that returns the pointer 
to XML_Memory_Handling_Suite for passed 
XML_Parser? It is necessary for me, I am developing an 
extension for Expat and I would like to use the same 
allocation/reallocation/free function as the current 
XML_Parser uses. Since XML_Parser struct defined 
inside .C-file, I can't get an access to 
XML_Memory_Handling_Suite struct for the parser. 
Please add this function, since it will be very simple.

Sincerely,
 Artyom Bolgar.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-16 17:15

Message:
Logged In: YES 
user_id=290026

Applied a patch with two solutions:

1) Added XML_FreeContentModel API
2) Exposed all three memory handling functions as
   XML_MemMalloc, XML_MemRealloc, XML_MemFree

Check out xmlparse.c rev. 1.102 and expat.h rev. 1.50

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-11 16:38

Message:
Logged In: YES 
user_id=290026

Artyom,

I think I understand now.
>From a proper design perspective your use case should
not involve Expat. This is a matter between your code
and the user's application. It should provide you with
the necessary information to use it properly.

However, I still think that there is a reason
for having an API like the one you suggested:

There is one use case where the application has to
free memory allocated by the parser (in the  element 
declaration handler).  If Expat is not accessed from 
C/C++,  then there may not be a way to do so
from languages that can access Dlls, but have different
memory allocation implementations.

In my case, I am lucky that Delphi's memory manager
is basically identical to C/C++, so I can create the
parser with the Delphi memory management functions.

However, I would have preferred if there was an API like 
you suggested, or at least a function to free the content 
model passed to the element declaration handler.

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

Comment By: Artyom Bolgar (artyom17)
Date: 2002-12-11 16:22

Message:
Logged In: YES 
user_id=657326

Karl,
Why user overloads memory allocation functions? Because 
he don't want to use malloc/realloc/free for some reasons, for 
example performance or compatibility (some embedded 
platforms do not support malloc/realloc/free functions). As far 
as I develops the extension of Expat and it will be linked 
together with Expat library I want to use the same memory 
functions as are used by parser.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-11 15:18

Message:
Logged In: YES 
user_id=290026

Artyom:
I am still not clear what you mean with overloading.
I don't think you need the same memory handler 
functions as Expat as long as you don't have to free
memory that Expat allocates.

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

Comment By: Artyom Bolgar (artyom17)
Date: 2002-12-11 15:14

Message:
Logged In: YES 
user_id=657326

I am developing an extension to Expat API that provides 
ability of parsing from any source, from file, network, etc. Of 
course, I have to make some memory allocations. For 
example, the function name EXML_CreateFileInputSource 
(XML_Parser, const char* filename). I don't know how 
XML_Parser was created, with mem suite or without. But I 
need to use the same memory functions as parser uses, 
because user might overload them.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-11 14:40

Message:
Logged In: YES 
user_id=290026

Attached is a potential patch MemSuite.diff.
Includes changes to expat.h, xmlparse.c
and the DEF files for Windows builds.

This is just a suggestion.
For the content model example all one would need,
however, is a FreeContentModel API.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-11 10:23

Message:
Logged In: YES 
user_id=290026

Fred:
I know that, but I just pointed out an example
where it would make sense.

I have another reason too that has to do with
writing wrappers/bindings for Expat, but I will
mention it in a reply to your upcoming message
on expat-discuss.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-12-11 09:38

Message:
Logged In: YES 
user_id=3066

Karl:  Artyom didn't say he was setting a handler on an
XML_Parser object someone else passed him, nor did he say he
wasn't.  The only specific I see here is that he wants to
use the same resource handlers as the parser; it's not clear
that this is a real requirement.  I'll follow up with a
discussion on expat-discuss.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-11 08:59

Message:
Logged In: YES 
user_id=290026

Once you set an element declaration handler you need
to free the content model passed to the handler, so
you will need to know the memory handler in use.

It is just a rare case that the code that sets the handlers
has no control over the code that creates the parser.
But it is not too far fetched, so IMO that feature
request makes some sense, unless I am overlooking
the obvious.

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

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

Message:
Logged In: YES 
user_id=3066

Can you explain why you need the memory handler they've
asked Expat to use?  The requirements aren't clear, so more
explanation of the use case should help.

Thanks.

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

Comment By: Artyom Bolgar (artyom17)
Date: 2002-12-11 06:32

Message:
Logged In: YES 
user_id=657326

Of course, I know about this. But in my case, I use 
XML_Parser passed by user (and it is created by him), and I 
don't know how it was created, either by 
XML_ParserCreate_MM or not. That is why I requested this 
function.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-10 21:24

Message:
Logged In: YES 
user_id=290026

Are you creating the parser using XML_ParserCreate?
In that case - without supplying an external memory handler,
Expat just uses the standard C runtime functions
malloc, realloc and free.

If you use XML_ParserCreate_MM however, then *you*
are supplying the memory handler yourself.

In both cases you don't need the requested function.

Is your situation different from what I described?

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

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

From noreply at sourceforge.net  Fri Jan 17 02:34:35 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan 17 05:31:36 2003
Subject: [Expat-bugs] [ expat-Bugs-538445 ] cc: -a conflicts with -dy
Message-ID: <E18ZTpb-0001gJ-00@sc8-sf-web3.sourceforge.net>

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

Category: Build control
Group: None
Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: cc: -a conflicts with -dy

Initial Comment:
I am trying to build expat on a sun solaris system and 
I get the following error during the build.

 cc: -a conflicts with -dy

I used the --prefix option during the ./configure 
execution.  Everything else was done just as the 
documentation suggested.

Any help would be much appreciated.

Thank you.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2003-01-17 02:34

Message:
Logged In: NO 

i had the same problem.  i untarred into directory expat-
1.95.2, ran make which crashed on the line

cc -o xmlwf -static xmlwf.o xmlfile.o codepage.o 
unixfilemap.o -L../lib/.libs -lexpat

with the error message 

cc: -a conflicts with -dy

i cd'ed into directory xmlwf, ran the above command manually 
replacing -static with -ds, then cd .. and make which then 
completed successfully.

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

Comment By: Greg Stein (gstein)
Date: 2002-05-17 18:05

Message:
Logged In: YES 
user_id=6501

duplicate of 553288


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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-04-25 18:30

Message:
Logged In: NO 

Isn't cc -flags shows:
-d[y|n]         dynamic [-dy] or static [-dn] option to linker

I simply changed -static to -dn and it worked fine

man ld shows-a    In static mode only,  produces  an 
executable  object
           file;  gives  errors for undefined references.
This is
           the default behavior for static mode. -a  may 
not  be
           used with the -r option.
 -d y | n
           When -d y, the default, is specified, ld uses 
dynamic
           linking;  when -d n is specified, ld uses static
link-
           ing. See also -B dynamic|static.




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

Comment By: Mathew Bevilacqua (matbev1)
Date: 2002-04-02 14:40

Message:
Logged In: YES 
user_id=501365

I, too, followed the instructions exactly, and some more 
tweaking was needed.  For my build to work, I had to:

1.  make sure that LIBTOOL in the makefile in /lib was set 
correctly 
2.  build as a super user

Also, you could try removing -dy.  It's just a debug 
utility.

>From the man page:
-dy    Dump debugging information during parsing, to 
standard error.


Mat Bevilacqua

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

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

From noreply at sourceforge.net  Fri Jan 17 09:52:12 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan 17 12:49:10 2003
Subject: [Expat-bugs] [ expat-Bugs-669861 ] storeRawNames and namespace
	processing
Message-ID: <E18Zaf6-0002uK-00@sc8-sf-web3.sourceforge.net>

Bugs item #669861, was opened at 2003-01-17 17:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=669861&group_id=10127

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

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

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

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

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

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

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

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

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

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

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

Keep a good work

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

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

From noreply at sourceforge.net  Fri Jan 17 10:19:42 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan 17 13:17:00 2003
Subject: [Expat-bugs] [ expat-Bugs-669861 ] storeRawNames and namespace
	processing
Message-ID: <E18Zb5i-00064P-00@sc8-sf-web4.sourceforge.net>

Bugs item #669861, was opened at 2003-01-17 12:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=669861&group_id=10127

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

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

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

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

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

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

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

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

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

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

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

Keep a good work

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

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

Message:
Logged In: YES 
user_id=290026

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

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

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

From noreply at sourceforge.net  Fri Jan 17 10:27:52 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan 17 13:25:12 2003
Subject: [Expat-bugs] [ expat-Bugs-669861 ] storeRawNames and namespace
	processing
Message-ID: <E18ZbDc-00053J-00@sc8-sf-web2.sourceforge.net>

Bugs item #669861, was opened at 2003-01-17 17:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=669861&group_id=10127

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

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

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

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

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

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

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

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

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

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

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

Keep a good work

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

>Comment By: Pavel Hlavnicka (pavel_hlavnicka)
Date: 2003-01-17 18:27

Message:
Logged In: YES 
user_id=302801

I'm using 1.95.5. I didn't check CVS, and would have to
check the source, not execution to prove it. The reason for
it is that the error is really hard to reporoduce.

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

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

Message:
Logged In: YES 
user_id=290026

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

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

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

From noreply at sourceforge.net  Fri Jan 17 10:40:24 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan 17 13:38:24 2003
Subject: [Expat-bugs] [ expat-Bugs-669861 ] storeRawNames and namespace
	processing
Message-ID: <E18ZbPk-00051b-00@sc8-sf-web3.sourceforge.net>

Bugs item #669861, was opened at 2003-01-17 12:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=669861&group_id=10127

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

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

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

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

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

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

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

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

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

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

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

Keep a good work

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

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

Message:
Logged In: YES 
user_id=290026

We hava a few fixes for storeRawNames in CVS.
Please check bugs #618199 and #667511 if they explain
the behaviour to you.

Before spending more time on it, I recommend you
run with CVS for a while and check if the problem
shows up again.

I also asked the user who reported these bugs first,
and he thinks your problem may be the same.

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

Comment By: Pavel Hlavnicka (pavel_hlavnicka)
Date: 2003-01-17 13:27

Message:
Logged In: YES 
user_id=302801

I'm using 1.95.5. I didn't check CVS, and would have to
check the source, not execution to prove it. The reason for
it is that the error is really hard to reporoduce.

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

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

Message:
Logged In: YES 
user_id=290026

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

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

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

From noreply at sourceforge.net  Fri Jan 17 10:55:55 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan 17 13:53:11 2003
Subject: [Expat-bugs] [ expat-Bugs-653180 ] problem with column and line
	numbers 
Message-ID: <E18Zbel-0007Tc-00@sc8-sf-web4.sourceforge.net>

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

Category: None
Group: Test Required
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: MM Zeeman (mmzeeman)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: problem with column and line numbers 

Initial Comment:

XML_GetCurrentColumnNumber returns 2 times the  actual
column 
number. The same holds for XML_GetCurrentLineNumber. The 
XML_GetCurrentByteIndex function returns the correct
value. 

The expat version i'm using is: expat_1.95.5



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

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

Message:
Logged In: YES 
user_id=290026

Fred,

I must be much younger than you, because I am not
aware of a historically established convention that
line-numbers are 1-based and column numbers are
0-based.  ;-)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-12-30 14:50

Message:
Logged In: YES 
user_id=3066

Tests added in tests/runtests.c revisions 1.40 and 1.41.
Documentation clarified as part of doc/reference.html 1.37.

Karl:  Line numbers traditionally start at 1, while column
numbers traditionally deal with insertion points (between
characters).  This is  a somewhat annoying inconsistency,
but historical in contexts well beyond Expat.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-16 12:33

Message:
Logged In: YES 
user_id=290026

Thanks a lot for the test cases. We are really grateful 
when somebody helps out! After all, this is a volunteer
effort.

About the HTML docs - they are usually a little behind.
If in doubt, check expat.h - or the source <g>.

And yes, Expat is good for wrappers. That is how I got 
into it (for Delphi). It supports basically everything 
needed to create a SAX2 wrapper with all SAX extensions.

Entity reporting, however, has the same limitations
as SAX, but we plan to find a way around it for a future 
release - so that Expat can provide everything needed
for building a DOM (it *almost* does).

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-12-16 11:18

Message:
Logged In: NO 

The HTML documentation tells me something different. It
indeed starts with an indication stating that these
functions are useful when XML_Parse returns 0, but also that
they are quote "the position reporting functions are useful
outside of errors. " It only states that it can not be used
inside a DTD.

So the situation was not really clear. What was clear is
that calling the line or column number function outside an
handler before final resulted in a wrong answer, and as a
bonus goofes up the further line and column number reports.

Btw I still think, Expat is a really good XML library. It
has a nice API, which makes it easy to create wrappers (I
was working on an expat wrapper for OCaml)

Here are the tests you requested:

/* 
 * Line and column numbers inside handlers test
 */

static void
start_element_event_handler2(void *userData, const XML_Char
*name,
			     const XML_Char **attr)
{
    CharData *storage = (CharData *) userData;
    char buffer[100];
    
    sprintf(buffer, "<%s> at col:%d line:%d\n", name, 
	    XML_GetCurrentColumnNumber(parser),
	    XML_GetCurrentLineNumber(parser));
    CharData_AppendString(storage, buffer);
}

static void
end_element_event_handler2(void *userData, const XML_Char *name)
{
    CharData *storage = (CharData *) userData;
    char buffer[100];

    sprintf(buffer, "</%s> at col:%d line:%d\n", name, 
	    XML_GetCurrentColumnNumber(parser),
	    XML_GetCurrentLineNumber(parser));
    CharData_AppendString(storage, buffer);
}

START_TEST(test_line_and_column_numbers_inside_handlers)
{
    char *text = "<a>\n"        /* the unix idea of an
end-of-line */
	         "  <b>\r\n"    /* the windows of an end-of-line*/
	         "    <c/>\r"   /* also counts as an end-of-line */
                 "  </b>\n"
                 "  <d>\n"
                 "    <f/>\n"
                 "  </d>\n"
                 "</a>";
    char *expected = "<a> at col:0 line:1\n"
	             "<b> at col:2 line:2\n"
	             "<c> at col:4 line:3\n"
	             "</c> at col:8 line:3\n"
	             "</b> at col:2 line:4\n"
	             "<d> at col:2 line:5\n"
	             "<f> at col:4 line:6\n"
	             "</f> at col:8 line:6\n"
	             "</d> at col:2 line:7\n"
	             "</a> at col:0 line:8\n";
    CharData storage;

    CharData_Init(&storage);
    XML_SetUserData(parser, &storage);
    XML_SetStartElementHandler(parser,
start_element_event_handler2);
    XML_SetEndElementHandler(parser,
end_element_event_handler2);
    if (XML_Parse(parser, text, strlen(text), 1) ==
XML_STATUS_ERROR)
        xml_failure(parser);

    CharData_CheckString(&storage, expected); 
}
END_TEST

START_TEST(test_line_number_after_error)
{
  char *text = "<a>\n"
               "  <b>\n"
               "  </a>"; /* missing </b> */
  int lineno;
  if (XML_Parse(parser, text, strlen(text), 0) !=
XML_STATUS_ERROR)
    fail("Expected a parse error");

  lineno = XML_GetCurrentLineNumber(parser);
  if (lineno != 3) {
    char buffer[100];
    sprintf(buffer, "expected 3 lines, saw %d", lineno);
    fail(buffer);
  }
}
END_TEST
    
START_TEST(test_column_number_after_error)
{
  char *text = "<a>\n"
               "  <b>\n"
               "  </a>"; /* missing </b> */
  int colno;
  if (XML_Parse(parser, text, strlen(text), 0) !=
XML_STATUS_ERROR)
    fail("Expected a parse error");

  colno = XML_GetCurrentColumnNumber(parser);
  if (colno != 4) { 
    char buffer[100];
    sprintf(buffer, "expected 4 columns, saw %d", colno);
    fail(buffer);
  }
}
END_TEST



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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-15 22:49

Message:
Logged In: YES 
user_id=290026

Just a comment:
According to the documentation in expat.h, the line/column
number functions should only be called when XML_Parse
or XML_ParseBuffer return 0 (error) or from callback handlers.

So, strictly speaking, this was not a bug.

Another question - mostly for Fred:
Why is it that line numbers are 1-based, and column
numbers are 0-based? If we keep this behaviour then
we should at least document it!

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

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

Message:
Logged In: YES 
user_id=290026

Great - I will apply a patch to CVS.
Could you please subject it to a few tests for other
situations, like:
- calling the line/column functions after an error
- calling them in a handler
And report back here. If OK, this patch will go into
the next release, which is coming soon.

To Fred Drake:
Fred, seems there is already a regression test case 
in the posts below. Would you please add it.


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

Comment By: MM Zeeman (mmzeeman)
Date: 2002-12-15 14:07

Message:
Logged In: YES 
user_id=350634

Thanks, this solved the problem. 

This was the first time I looked at the expat code, so I was
a bit surprised to see that XML parsing is not as simple as
I thought it would be. On the other hand, maybe the code
needs to be refactored here and there too. 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-15 11:34

Message:
Logged In: YES 
user_id=290026

OK, I think this will be better.
Same places as before, but instead of the previous 
statements insert these after XMLUpdatePosition:

in XML_Parse(): positionPtr = end;
in XML_ParseBuffer(): positionPtr = bufferPtr;

Why is it not part of the scanning routines?
I can only guess, since I didn't write it.
I would say that
a) it would make the code even more complicated
b) it would likely not be faster

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

Comment By: MM Zeeman (mmzeeman)
Date: 2002-12-15 11:20

Message:
Logged In: YES 
user_id=350634

No, this does not solve the problem.

tests/runtests
Running suite(s): basic
93%: Checks: 31, Failures: 2, Errors: 0
tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7
tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22
make: *** [check] Error 1

Btw, this whole line/column counting seems to be one big
side-effect ;) Why is
it not implemented as part of the normal scanning routines.
It seems like the buffer passed to XML_Parse will be checked
(again) just to adjust the line and column numbers. During
the "normal" scanning phase nothing is done to adjust the
line and column numbers. 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-15 01:54

Message:
Logged In: YES 
user_id=290026

Try this - not tested:

in XML_Parse(), right after XMLUpdatePosition,
insert this line:

  eventPtr = eventEndPtr = end;

and in XML_ParseBuffer, also right after XMLUpdatePosition,
insert (as part of the conditional statement):

  eventPtr = eventEndPtr = bufferPtr;

That should hopefully prevent double counting.
Haven't really checked possible side-effects.


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

Comment By: MM Zeeman (mmzeeman)
Date: 2002-12-15 00:48

Message:
Logged In: YES 
user_id=350634

Hmm,

It looks more like the line and column numbers are counted
double outside the handlers. When I added this piece of code
in front of the update routine the counting was correct.
Looking at the source if found that outside the handers the
update is called twice. It is first called in parse, and
later when you call either XML_GetCurrentLineNumber, or
XML_GetCurrentColumnNumber, because for some reason the
eventPtr is set. (Which to me seems like this should only be
the case in handlers, but I'm not sure)

 static void FASTCALL
PREFIX(updatePosition)(const ENCODING *enc,
                       const char *ptr,
                       const char *end,
                       POSITION *pos)
{     
  /* THIS IS NOT CORRECT
   * Yes, this is lame, but it helps to indicate a double 
   * counting the newlines and column number problem 
   */   
  static const char *s_ptr = NULL;
  static const char *s_end = NULL;
  if( (s_ptr == ptr) && (s_end == end))
    /* we already counted this one */
    return;
  s_ptr = ptr; s_end = end;

/* The rest of the function */

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-14 11:41

Message:
Logged In: YES 
user_id=290026

I have looked a little closer.
It seems the numbers are reported OK only if the
parser is at the end or beginning of a token, but not
in-between. Btw, the line/column number relates
to the start of the token, as far as I can tell from the source.

In your example, isFinal = 0, so the parser is in-between 
tokens and expects at least one more call to XML_Parse.
I am not sure it is OK to call the line/column number
functions in between calls to XML_Parse, since at this point
the parser is in the middle of processing a token, while
in the other situations (inside a handler, and when having an 
error) the parser knows exactly what the current token is
or is not.

One thing is sure: The documentation is not clear and 
sufficient. Also, from what I can tell, line numbers are
1-based and column numbers are 0-based. I don't think
that is a good idea. It should probably be consistent
with SAX, where both numbers are 1-based.


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

Comment By: MM Zeeman (mmzeeman)
Date: 2002-12-14 11:22

Message:
Logged In: YES 
user_id=350634

When I set a start element handler the line number reporting
is fine, as long as no trailing newlines are inserted after
the last tag. When instead of a start element handler a end
element handler is set the line-number is always wrong.
Inside the handlers the line-numbers are always ok. 

I did not check the behavoir for xml_parse errors, or the
column number (yet).



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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-13 21:18

Message:
Logged In: YES 
user_id=290026

Does this also happen in other situations?
For instance:
- inside a handler
- when XML_Parse returns with an error?

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

Comment By: MM Zeeman (mmzeeman)
Date: 2002-12-13 06:01

Message:
Logged In: YES 
user_id=350634

I forgot to add the tests:

START_TEST(test_line_number_maas)
{  
  char *text = "<tag>\n"
               "\n"
               "\n</tag>";
  int lineno;
  if (XML_Parse(parser, text, strlen(text), 0) ==
XML_STATUS_ERROR)
      xml_failure(parser);
  lineno = XML_GetCurrentLineNumber(parser);
  if (lineno != 4) {
      char buffer[100];
      sprintf(buffer, "expected 4 lines, saw %d", lineno);
      fail(buffer);
  }
}
END_TEST

START_TEST(test_column_number_maas)
{
  char *text = "<tag></tag>";
  int colno;
  if (XML_Parse(parser, text, strlen(text), 0) ==
XML_STATUS_ERROR)
            xml_failure(parser);
  colno = XML_GetCurrentColumnNumber(parser);
  if (colno != 11) {
      char buffer[100];
      sprintf(buffer, "expected 11 columns, saw %d", colno);
      fail(buffer);
  }
}
END_TEST

Added to the test suite this resulted in:

Running suite(s): basic
93%: Checks: 31, Failures: 2, Errors: 0
tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7
tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22

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

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

From noreply at sourceforge.net  Fri Jan 17 11:05:09 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan 17 14:02:25 2003
Subject: [Expat-bugs] [ expat-Bugs-653180 ] problem with column and line
	numbers 
Message-ID: <E18Zbnh-0006ua-00@sc8-sf-web2.sourceforge.net>

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

Category: None
Group: Test Required
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: MM Zeeman (mmzeeman)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: problem with column and line numbers 

Initial Comment:

XML_GetCurrentColumnNumber returns 2 times the  actual
column 
number. The same holds for XML_GetCurrentLineNumber. The 
XML_GetCurrentByteIndex function returns the correct
value. 

The expat version i'm using is: expat_1.95.5



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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-17 14:05

Message:
Logged In: YES 
user_id=3066

Karl,

So I guess that makes you either a small child or a Windows
user.  ;-)

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

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

Message:
Logged In: YES 
user_id=290026

Fred,

I must be much younger than you, because I am not
aware of a historically established convention that
line-numbers are 1-based and column numbers are
0-based.  ;-)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-12-30 14:50

Message:
Logged In: YES 
user_id=3066

Tests added in tests/runtests.c revisions 1.40 and 1.41.
Documentation clarified as part of doc/reference.html 1.37.

Karl:  Line numbers traditionally start at 1, while column
numbers traditionally deal with insertion points (between
characters).  This is  a somewhat annoying inconsistency,
but historical in contexts well beyond Expat.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-16 12:33

Message:
Logged In: YES 
user_id=290026

Thanks a lot for the test cases. We are really grateful 
when somebody helps out! After all, this is a volunteer
effort.

About the HTML docs - they are usually a little behind.
If in doubt, check expat.h - or the source <g>.

And yes, Expat is good for wrappers. That is how I got 
into it (for Delphi). It supports basically everything 
needed to create a SAX2 wrapper with all SAX extensions.

Entity reporting, however, has the same limitations
as SAX, but we plan to find a way around it for a future 
release - so that Expat can provide everything needed
for building a DOM (it *almost* does).

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-12-16 11:18

Message:
Logged In: NO 

The HTML documentation tells me something different. It
indeed starts with an indication stating that these
functions are useful when XML_Parse returns 0, but also that
they are quote "the position reporting functions are useful
outside of errors. " It only states that it can not be used
inside a DTD.

So the situation was not really clear. What was clear is
that calling the line or column number function outside an
handler before final resulted in a wrong answer, and as a
bonus goofes up the further line and column number reports.

Btw I still think, Expat is a really good XML library. It
has a nice API, which makes it easy to create wrappers (I
was working on an expat wrapper for OCaml)

Here are the tests you requested:

/* 
 * Line and column numbers inside handlers test
 */

static void
start_element_event_handler2(void *userData, const XML_Char
*name,
			     const XML_Char **attr)
{
    CharData *storage = (CharData *) userData;
    char buffer[100];
    
    sprintf(buffer, "<%s> at col:%d line:%d\n", name, 
	    XML_GetCurrentColumnNumber(parser),
	    XML_GetCurrentLineNumber(parser));
    CharData_AppendString(storage, buffer);
}

static void
end_element_event_handler2(void *userData, const XML_Char *name)
{
    CharData *storage = (CharData *) userData;
    char buffer[100];

    sprintf(buffer, "</%s> at col:%d line:%d\n", name, 
	    XML_GetCurrentColumnNumber(parser),
	    XML_GetCurrentLineNumber(parser));
    CharData_AppendString(storage, buffer);
}

START_TEST(test_line_and_column_numbers_inside_handlers)
{
    char *text = "<a>\n"        /* the unix idea of an
end-of-line */
	         "  <b>\r\n"    /* the windows of an end-of-line*/
	         "    <c/>\r"   /* also counts as an end-of-line */
                 "  </b>\n"
                 "  <d>\n"
                 "    <f/>\n"
                 "  </d>\n"
                 "</a>";
    char *expected = "<a> at col:0 line:1\n"
	             "<b> at col:2 line:2\n"
	             "<c> at col:4 line:3\n"
	             "</c> at col:8 line:3\n"
	             "</b> at col:2 line:4\n"
	             "<d> at col:2 line:5\n"
	             "<f> at col:4 line:6\n"
	             "</f> at col:8 line:6\n"
	             "</d> at col:2 line:7\n"
	             "</a> at col:0 line:8\n";
    CharData storage;

    CharData_Init(&storage);
    XML_SetUserData(parser, &storage);
    XML_SetStartElementHandler(parser,
start_element_event_handler2);
    XML_SetEndElementHandler(parser,
end_element_event_handler2);
    if (XML_Parse(parser, text, strlen(text), 1) ==
XML_STATUS_ERROR)
        xml_failure(parser);

    CharData_CheckString(&storage, expected); 
}
END_TEST

START_TEST(test_line_number_after_error)
{
  char *text = "<a>\n"
               "  <b>\n"
               "  </a>"; /* missing </b> */
  int lineno;
  if (XML_Parse(parser, text, strlen(text), 0) !=
XML_STATUS_ERROR)
    fail("Expected a parse error");

  lineno = XML_GetCurrentLineNumber(parser);
  if (lineno != 3) {
    char buffer[100];
    sprintf(buffer, "expected 3 lines, saw %d", lineno);
    fail(buffer);
  }
}
END_TEST
    
START_TEST(test_column_number_after_error)
{
  char *text = "<a>\n"
               "  <b>\n"
               "  </a>"; /* missing </b> */
  int colno;
  if (XML_Parse(parser, text, strlen(text), 0) !=
XML_STATUS_ERROR)
    fail("Expected a parse error");

  colno = XML_GetCurrentColumnNumber(parser);
  if (colno != 4) { 
    char buffer[100];
    sprintf(buffer, "expected 4 columns, saw %d", colno);
    fail(buffer);
  }
}
END_TEST



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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-15 22:49

Message:
Logged In: YES 
user_id=290026

Just a comment:
According to the documentation in expat.h, the line/column
number functions should only be called when XML_Parse
or XML_ParseBuffer return 0 (error) or from callback handlers.

So, strictly speaking, this was not a bug.

Another question - mostly for Fred:
Why is it that line numbers are 1-based, and column
numbers are 0-based? If we keep this behaviour then
we should at least document it!

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

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

Message:
Logged In: YES 
user_id=290026

Great - I will apply a patch to CVS.
Could you please subject it to a few tests for other
situations, like:
- calling the line/column functions after an error
- calling them in a handler
And report back here. If OK, this patch will go into
the next release, which is coming soon.

To Fred Drake:
Fred, seems there is already a regression test case 
in the posts below. Would you please add it.


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

Comment By: MM Zeeman (mmzeeman)
Date: 2002-12-15 14:07

Message:
Logged In: YES 
user_id=350634

Thanks, this solved the problem. 

This was the first time I looked at the expat code, so I was
a bit surprised to see that XML parsing is not as simple as
I thought it would be. On the other hand, maybe the code
needs to be refactored here and there too. 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-15 11:34

Message:
Logged In: YES 
user_id=290026

OK, I think this will be better.
Same places as before, but instead of the previous 
statements insert these after XMLUpdatePosition:

in XML_Parse(): positionPtr = end;
in XML_ParseBuffer(): positionPtr = bufferPtr;

Why is it not part of the scanning routines?
I can only guess, since I didn't write it.
I would say that
a) it would make the code even more complicated
b) it would likely not be faster

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

Comment By: MM Zeeman (mmzeeman)
Date: 2002-12-15 11:20

Message:
Logged In: YES 
user_id=350634

No, this does not solve the problem.

tests/runtests
Running suite(s): basic
93%: Checks: 31, Failures: 2, Errors: 0
tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7
tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22
make: *** [check] Error 1

Btw, this whole line/column counting seems to be one big
side-effect ;) Why is
it not implemented as part of the normal scanning routines.
It seems like the buffer passed to XML_Parse will be checked
(again) just to adjust the line and column numbers. During
the "normal" scanning phase nothing is done to adjust the
line and column numbers. 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-15 01:54

Message:
Logged In: YES 
user_id=290026

Try this - not tested:

in XML_Parse(), right after XMLUpdatePosition,
insert this line:

  eventPtr = eventEndPtr = end;

and in XML_ParseBuffer, also right after XMLUpdatePosition,
insert (as part of the conditional statement):

  eventPtr = eventEndPtr = bufferPtr;

That should hopefully prevent double counting.
Haven't really checked possible side-effects.


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

Comment By: MM Zeeman (mmzeeman)
Date: 2002-12-15 00:48

Message:
Logged In: YES 
user_id=350634

Hmm,

It looks more like the line and column numbers are counted
double outside the handlers. When I added this piece of code
in front of the update routine the counting was correct.
Looking at the source if found that outside the handers the
update is called twice. It is first called in parse, and
later when you call either XML_GetCurrentLineNumber, or
XML_GetCurrentColumnNumber, because for some reason the
eventPtr is set. (Which to me seems like this should only be
the case in handlers, but I'm not sure)

 static void FASTCALL
PREFIX(updatePosition)(const ENCODING *enc,
                       const char *ptr,
                       const char *end,
                       POSITION *pos)
{     
  /* THIS IS NOT CORRECT
   * Yes, this is lame, but it helps to indicate a double 
   * counting the newlines and column number problem 
   */   
  static const char *s_ptr = NULL;
  static const char *s_end = NULL;
  if( (s_ptr == ptr) && (s_end == end))
    /* we already counted this one */
    return;
  s_ptr = ptr; s_end = end;

/* The rest of the function */

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-14 11:41

Message:
Logged In: YES 
user_id=290026

I have looked a little closer.
It seems the numbers are reported OK only if the
parser is at the end or beginning of a token, but not
in-between. Btw, the line/column number relates
to the start of the token, as far as I can tell from the source.

In your example, isFinal = 0, so the parser is in-between 
tokens and expects at least one more call to XML_Parse.
I am not sure it is OK to call the line/column number
functions in between calls to XML_Parse, since at this point
the parser is in the middle of processing a token, while
in the other situations (inside a handler, and when having an 
error) the parser knows exactly what the current token is
or is not.

One thing is sure: The documentation is not clear and 
sufficient. Also, from what I can tell, line numbers are
1-based and column numbers are 0-based. I don't think
that is a good idea. It should probably be consistent
with SAX, where both numbers are 1-based.


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

Comment By: MM Zeeman (mmzeeman)
Date: 2002-12-14 11:22

Message:
Logged In: YES 
user_id=350634

When I set a start element handler the line number reporting
is fine, as long as no trailing newlines are inserted after
the last tag. When instead of a start element handler a end
element handler is set the line-number is always wrong.
Inside the handlers the line-numbers are always ok. 

I did not check the behavoir for xml_parse errors, or the
column number (yet).



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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-13 21:18

Message:
Logged In: YES 
user_id=290026

Does this also happen in other situations?
For instance:
- inside a handler
- when XML_Parse returns with an error?

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

Comment By: MM Zeeman (mmzeeman)
Date: 2002-12-13 06:01

Message:
Logged In: YES 
user_id=350634

I forgot to add the tests:

START_TEST(test_line_number_maas)
{  
  char *text = "<tag>\n"
               "\n"
               "\n</tag>";
  int lineno;
  if (XML_Parse(parser, text, strlen(text), 0) ==
XML_STATUS_ERROR)
      xml_failure(parser);
  lineno = XML_GetCurrentLineNumber(parser);
  if (lineno != 4) {
      char buffer[100];
      sprintf(buffer, "expected 4 lines, saw %d", lineno);
      fail(buffer);
  }
}
END_TEST

START_TEST(test_column_number_maas)
{
  char *text = "<tag></tag>";
  int colno;
  if (XML_Parse(parser, text, strlen(text), 0) ==
XML_STATUS_ERROR)
            xml_failure(parser);
  colno = XML_GetCurrentColumnNumber(parser);
  if (colno != 11) {
      char buffer[100];
      sprintf(buffer, "expected 11 columns, saw %d", colno);
      fail(buffer);
  }
}
END_TEST

Added to the test suite this resulted in:

Running suite(s): basic
93%: Checks: 31, Failures: 2, Errors: 0
tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7
tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22

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

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

From noreply at sourceforge.net  Fri Jan 17 11:11:30 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan 17 14:08:33 2003
Subject: [Expat-bugs] [ expat-Bugs-653180 ] problem with column and line
	numbers 
Message-ID: <E18Zbtq-0006bb-00@sc8-sf-web3.sourceforge.net>

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

Category: None
Group: Test Required
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: MM Zeeman (mmzeeman)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: problem with column and line numbers 

Initial Comment:

XML_GetCurrentColumnNumber returns 2 times the  actual
column 
number. The same holds for XML_GetCurrentLineNumber. The 
XML_GetCurrentByteIndex function returns the correct
value. 

The expat version i'm using is: expat_1.95.5



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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-17 14:11

Message:
Logged In: YES 
user_id=290026

I think you hit the nail on the head in both cases. ;-)))

Anyay, both MS VC++ and Delphi show me column 
numbers as 1-based.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-17 14:05

Message:
Logged In: YES 
user_id=3066

Karl,

So I guess that makes you either a small child or a Windows
user.  ;-)

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

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

Message:
Logged In: YES 
user_id=290026

Fred,

I must be much younger than you, because I am not
aware of a historically established convention that
line-numbers are 1-based and column numbers are
0-based.  ;-)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-12-30 14:50

Message:
Logged In: YES 
user_id=3066

Tests added in tests/runtests.c revisions 1.40 and 1.41.
Documentation clarified as part of doc/reference.html 1.37.

Karl:  Line numbers traditionally start at 1, while column
numbers traditionally deal with insertion points (between
characters).  This is  a somewhat annoying inconsistency,
but historical in contexts well beyond Expat.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-16 12:33

Message:
Logged In: YES 
user_id=290026

Thanks a lot for the test cases. We are really grateful 
when somebody helps out! After all, this is a volunteer
effort.

About the HTML docs - they are usually a little behind.
If in doubt, check expat.h - or the source <g>.

And yes, Expat is good for wrappers. That is how I got 
into it (for Delphi). It supports basically everything 
needed to create a SAX2 wrapper with all SAX extensions.

Entity reporting, however, has the same limitations
as SAX, but we plan to find a way around it for a future 
release - so that Expat can provide everything needed
for building a DOM (it *almost* does).

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-12-16 11:18

Message:
Logged In: NO 

The HTML documentation tells me something different. It
indeed starts with an indication stating that these
functions are useful when XML_Parse returns 0, but also that
they are quote "the position reporting functions are useful
outside of errors. " It only states that it can not be used
inside a DTD.

So the situation was not really clear. What was clear is
that calling the line or column number function outside an
handler before final resulted in a wrong answer, and as a
bonus goofes up the further line and column number reports.

Btw I still think, Expat is a really good XML library. It
has a nice API, which makes it easy to create wrappers (I
was working on an expat wrapper for OCaml)

Here are the tests you requested:

/* 
 * Line and column numbers inside handlers test
 */

static void
start_element_event_handler2(void *userData, const XML_Char
*name,
			     const XML_Char **attr)
{
    CharData *storage = (CharData *) userData;
    char buffer[100];
    
    sprintf(buffer, "<%s> at col:%d line:%d\n", name, 
	    XML_GetCurrentColumnNumber(parser),
	    XML_GetCurrentLineNumber(parser));
    CharData_AppendString(storage, buffer);
}

static void
end_element_event_handler2(void *userData, const XML_Char *name)
{
    CharData *storage = (CharData *) userData;
    char buffer[100];

    sprintf(buffer, "</%s> at col:%d line:%d\n", name, 
	    XML_GetCurrentColumnNumber(parser),
	    XML_GetCurrentLineNumber(parser));
    CharData_AppendString(storage, buffer);
}

START_TEST(test_line_and_column_numbers_inside_handlers)
{
    char *text = "<a>\n"        /* the unix idea of an
end-of-line */
	         "  <b>\r\n"    /* the windows of an end-of-line*/
	         "    <c/>\r"   /* also counts as an end-of-line */
                 "  </b>\n"
                 "  <d>\n"
                 "    <f/>\n"
                 "  </d>\n"
                 "</a>";
    char *expected = "<a> at col:0 line:1\n"
	             "<b> at col:2 line:2\n"
	             "<c> at col:4 line:3\n"
	             "</c> at col:8 line:3\n"
	             "</b> at col:2 line:4\n"
	             "<d> at col:2 line:5\n"
	             "<f> at col:4 line:6\n"
	             "</f> at col:8 line:6\n"
	             "</d> at col:2 line:7\n"
	             "</a> at col:0 line:8\n";
    CharData storage;

    CharData_Init(&storage);
    XML_SetUserData(parser, &storage);
    XML_SetStartElementHandler(parser,
start_element_event_handler2);
    XML_SetEndElementHandler(parser,
end_element_event_handler2);
    if (XML_Parse(parser, text, strlen(text), 1) ==
XML_STATUS_ERROR)
        xml_failure(parser);

    CharData_CheckString(&storage, expected); 
}
END_TEST

START_TEST(test_line_number_after_error)
{
  char *text = "<a>\n"
               "  <b>\n"
               "  </a>"; /* missing </b> */
  int lineno;
  if (XML_Parse(parser, text, strlen(text), 0) !=
XML_STATUS_ERROR)
    fail("Expected a parse error");

  lineno = XML_GetCurrentLineNumber(parser);
  if (lineno != 3) {
    char buffer[100];
    sprintf(buffer, "expected 3 lines, saw %d", lineno);
    fail(buffer);
  }
}
END_TEST
    
START_TEST(test_column_number_after_error)
{
  char *text = "<a>\n"
               "  <b>\n"
               "  </a>"; /* missing </b> */
  int colno;
  if (XML_Parse(parser, text, strlen(text), 0) !=
XML_STATUS_ERROR)
    fail("Expected a parse error");

  colno = XML_GetCurrentColumnNumber(parser);
  if (colno != 4) { 
    char buffer[100];
    sprintf(buffer, "expected 4 columns, saw %d", colno);
    fail(buffer);
  }
}
END_TEST



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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-15 22:49

Message:
Logged In: YES 
user_id=290026

Just a comment:
According to the documentation in expat.h, the line/column
number functions should only be called when XML_Parse
or XML_ParseBuffer return 0 (error) or from callback handlers.

So, strictly speaking, this was not a bug.

Another question - mostly for Fred:
Why is it that line numbers are 1-based, and column
numbers are 0-based? If we keep this behaviour then
we should at least document it!

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

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

Message:
Logged In: YES 
user_id=290026

Great - I will apply a patch to CVS.
Could you please subject it to a few tests for other
situations, like:
- calling the line/column functions after an error
- calling them in a handler
And report back here. If OK, this patch will go into
the next release, which is coming soon.

To Fred Drake:
Fred, seems there is already a regression test case 
in the posts below. Would you please add it.


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

Comment By: MM Zeeman (mmzeeman)
Date: 2002-12-15 14:07

Message:
Logged In: YES 
user_id=350634

Thanks, this solved the problem. 

This was the first time I looked at the expat code, so I was
a bit surprised to see that XML parsing is not as simple as
I thought it would be. On the other hand, maybe the code
needs to be refactored here and there too. 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-15 11:34

Message:
Logged In: YES 
user_id=290026

OK, I think this will be better.
Same places as before, but instead of the previous 
statements insert these after XMLUpdatePosition:

in XML_Parse(): positionPtr = end;
in XML_ParseBuffer(): positionPtr = bufferPtr;

Why is it not part of the scanning routines?
I can only guess, since I didn't write it.
I would say that
a) it would make the code even more complicated
b) it would likely not be faster

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

Comment By: MM Zeeman (mmzeeman)
Date: 2002-12-15 11:20

Message:
Logged In: YES 
user_id=350634

No, this does not solve the problem.

tests/runtests
Running suite(s): basic
93%: Checks: 31, Failures: 2, Errors: 0
tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7
tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22
make: *** [check] Error 1

Btw, this whole line/column counting seems to be one big
side-effect ;) Why is
it not implemented as part of the normal scanning routines.
It seems like the buffer passed to XML_Parse will be checked
(again) just to adjust the line and column numbers. During
the "normal" scanning phase nothing is done to adjust the
line and column numbers. 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-15 01:54

Message:
Logged In: YES 
user_id=290026

Try this - not tested:

in XML_Parse(), right after XMLUpdatePosition,
insert this line:

  eventPtr = eventEndPtr = end;

and in XML_ParseBuffer, also right after XMLUpdatePosition,
insert (as part of the conditional statement):

  eventPtr = eventEndPtr = bufferPtr;

That should hopefully prevent double counting.
Haven't really checked possible side-effects.


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

Comment By: MM Zeeman (mmzeeman)
Date: 2002-12-15 00:48

Message:
Logged In: YES 
user_id=350634

Hmm,

It looks more like the line and column numbers are counted
double outside the handlers. When I added this piece of code
in front of the update routine the counting was correct.
Looking at the source if found that outside the handers the
update is called twice. It is first called in parse, and
later when you call either XML_GetCurrentLineNumber, or
XML_GetCurrentColumnNumber, because for some reason the
eventPtr is set. (Which to me seems like this should only be
the case in handlers, but I'm not sure)

 static void FASTCALL
PREFIX(updatePosition)(const ENCODING *enc,
                       const char *ptr,
                       const char *end,
                       POSITION *pos)
{     
  /* THIS IS NOT CORRECT
   * Yes, this is lame, but it helps to indicate a double 
   * counting the newlines and column number problem 
   */   
  static const char *s_ptr = NULL;
  static const char *s_end = NULL;
  if( (s_ptr == ptr) && (s_end == end))
    /* we already counted this one */
    return;
  s_ptr = ptr; s_end = end;

/* The rest of the function */

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-14 11:41

Message:
Logged In: YES 
user_id=290026

I have looked a little closer.
It seems the numbers are reported OK only if the
parser is at the end or beginning of a token, but not
in-between. Btw, the line/column number relates
to the start of the token, as far as I can tell from the source.

In your example, isFinal = 0, so the parser is in-between 
tokens and expects at least one more call to XML_Parse.
I am not sure it is OK to call the line/column number
functions in between calls to XML_Parse, since at this point
the parser is in the middle of processing a token, while
in the other situations (inside a handler, and when having an 
error) the parser knows exactly what the current token is
or is not.

One thing is sure: The documentation is not clear and 
sufficient. Also, from what I can tell, line numbers are
1-based and column numbers are 0-based. I don't think
that is a good idea. It should probably be consistent
with SAX, where both numbers are 1-based.


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

Comment By: MM Zeeman (mmzeeman)
Date: 2002-12-14 11:22

Message:
Logged In: YES 
user_id=350634

When I set a start element handler the line number reporting
is fine, as long as no trailing newlines are inserted after
the last tag. When instead of a start element handler a end
element handler is set the line-number is always wrong.
Inside the handlers the line-numbers are always ok. 

I did not check the behavoir for xml_parse errors, or the
column number (yet).



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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-13 21:18

Message:
Logged In: YES 
user_id=290026

Does this also happen in other situations?
For instance:
- inside a handler
- when XML_Parse returns with an error?

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

Comment By: MM Zeeman (mmzeeman)
Date: 2002-12-13 06:01

Message:
Logged In: YES 
user_id=350634

I forgot to add the tests:

START_TEST(test_line_number_maas)
{  
  char *text = "<tag>\n"
               "\n"
               "\n</tag>";
  int lineno;
  if (XML_Parse(parser, text, strlen(text), 0) ==
XML_STATUS_ERROR)
      xml_failure(parser);
  lineno = XML_GetCurrentLineNumber(parser);
  if (lineno != 4) {
      char buffer[100];
      sprintf(buffer, "expected 4 lines, saw %d", lineno);
      fail(buffer);
  }
}
END_TEST

START_TEST(test_column_number_maas)
{
  char *text = "<tag></tag>";
  int colno;
  if (XML_Parse(parser, text, strlen(text), 0) ==
XML_STATUS_ERROR)
            xml_failure(parser);
  colno = XML_GetCurrentColumnNumber(parser);
  if (colno != 11) {
      char buffer[100];
      sprintf(buffer, "expected 11 columns, saw %d", colno);
      fail(buffer);
  }
}
END_TEST

Added to the test suite this resulted in:

Running suite(s): basic
93%: Checks: 31, Failures: 2, Errors: 0
tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7
tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22

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

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

From noreply at sourceforge.net  Sun Jan 19 10:58:47 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jan 19 13:55:25 2003
Subject: [Expat-bugs] [ expat-Bugs-615272 ] Expat 1.95.5 static library name
Message-ID: <E18aKed-0001r7-00@sc8-sf-web3.sourceforge.net>

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

Category: None
Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Expat 1.95.5 static library name

Initial Comment:
Expat 1.95.5 on Win32 using MSVC.

I think its great that you include a static library now!  It 
would be more convenient for our build environment 
though if you called the static .lib files something 
different than the DLL stub .lib files so that they can live 
in the same directory. Of course, anyone building expat 
could do this, but it would be nice to have it this way out 
of the box. You could then move these files into 
the "Libs" directory, and delete the "StaticLibs" directory.

For other libraries, I've seen "static" appended to the 
name.  Another thing that is often done with MSVC 
static libraries is to have multiple version based on how 
you link with the CRT - /MT (Multithreaded) or /MD 
(Multithreaded DLL) - and to append MT or MD to the 
name.  This way you can use the appropriate static 
library depending on your situation. It's also common to 
keep everything in one .dsp, and use multiple 
configurations.  So instead of 4 .dsp files, you'd have 
1 .dsp with the configurations:

Win32 Debug DLL
  (libexpat.dll and stub libexpat.lib)
Win32 Debug Static MT
  (static libexpatMT.lib)
Win32 Debug Static MD
  (static libexpatMD.lib)

Win32 Release DLL
  (libexpat.dll and stub libexpat.lib)
Win32 Release Static MT
  (static libexpatMT.lib)
Win32 Release Static MD
  (static libexpatMD.lib)

Win32 Unicode Debug DLL
  (libexpatw.dll and stub libexpatw.lib)
Win32 Unicode Debug Static MT
  (static libexpatwMT.lib)
Win32 Unicode Debug Static MD
  (static libexpatwMD.lib)

Win32 Unicode Release DLL
  (libexpatw.dll and stub libexpatw.lib)
Win32 Unicode Release Static MT
  (static libexpatwMT.lib)
Win32 Unicode Release Static MD
  (static libexpatwMD.lib)

It would also be nice if instead of needing to 
define "_STATIC",  it was something a little more 
specific like "_EXPAT_STATIC" or even "XML_STATIC".

Thanks!

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

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

Message:
Logged In: YES 
user_id=290026

I didn't find a good way to change the project configuration.
Each alternative has drawbacks, so let's leave it as is.

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

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

Message:
Logged In: YES 
user_id=290026

For the 1.95.6 release I have made the following 
changes:

- The static projects now build libexpatMT.lib and
   libexpatwMT.lib by default (i.e. linked to the 
   multithreaded runtime Dll)
- in ../Win32/ReadMe.txt there are instructions for
   how to build the static libs linked to the two other
   versions of the runtime lib (single-threaded and
   multi-threaded static)
- The naming conventions follow the MS standard
   (using the MT, ML, MD postfixes)
- _STATIC was changed to XML_STATIC

I have not had time to change to a more project
configuration oriented setup (as described in the
original feature request note).

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-09-26 19:39

Message:
Logged In: YES 
user_id=290026

Since you already seem to know exactly what to do,
why don't you submit a patch with these changes?
We would certainly have a look at it, and there is a good 
chance it could be included in the next release.

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

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

From noreply at sourceforge.net  Sun Jan 19 11:01:45 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jan 19 13:58:26 2003
Subject: [Expat-bugs] [ expat-Bugs-569461 ] 1.95.3 and new OASIS xml test
	suite
Message-ID: <E18aKhV-0001vN-00@sc8-sf-web3.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: Accepted
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: 2003-01-19 14:01

Message:
Logged In: YES 
user_id=290026

Just a comment:
This bug report will likely stay open until Expat passes the
OASIS test suite without any problem at all.
Since no parser currently achieves this, there is a good
chance this bug report will stay open for a long time to come..


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

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 at sourceforge.net  Mon Jan 20 01:28:09 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jan 20 04:24:56 2003
Subject: [Expat-bugs] [ expat-Bugs-669861 ] storeRawNames and namespace
	processing
Message-ID: <E18aYDx-0005Hw-00@sc8-sf-web4.sourceforge.net>

Bugs item #669861, was opened at 2003-01-17 17:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=669861&group_id=10127

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

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

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

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

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

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

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

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

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

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

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

Keep a good work

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

>Comment By: Pavel Hlavnicka (pavel_hlavnicka)
Date: 2003-01-20 09:28

Message:
Logged In: YES 
user_id=302801

Bugs you pointed seem be of the similar flavour. Especially
#667511. 

I'd like to try the CVS version, but my system uses older
version of autoconf, and I have got some reasons not to upgrade.

If you want me to test it, please be so nice, and make a
test distribution for me. Sorry and thanks.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-17 18:40

Message:
Logged In: YES 
user_id=290026

We hava a few fixes for storeRawNames in CVS.
Please check bugs #618199 and #667511 if they explain
the behaviour to you.

Before spending more time on it, I recommend you
run with CVS for a while and check if the problem
shows up again.

I also asked the user who reported these bugs first,
and he thinks your problem may be the same.

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

Comment By: Pavel Hlavnicka (pavel_hlavnicka)
Date: 2003-01-17 18:27

Message:
Logged In: YES 
user_id=302801

I'm using 1.95.5. I didn't check CVS, and would have to
check the source, not execution to prove it. The reason for
it is that the error is really hard to reporoduce.

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

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

Message:
Logged In: YES 
user_id=290026

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

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

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

From noreply at sourceforge.net  Mon Jan 20 08:00:24 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jan 20 10:57:16 2003
Subject: [Expat-bugs] [ expat-Bugs-669861 ] storeRawNames and namespace
	processing
Message-ID: <E18aeLY-0007z6-00@sc8-sf-web2.sourceforge.net>

Bugs item #669861, was opened at 2003-01-17 17:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=669861&group_id=10127

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

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

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

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

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

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

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

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

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

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

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

Keep a good work

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

>Comment By: Pavel Hlavnicka (pavel_hlavnicka)
Date: 2003-01-20 16:00

Message:
Logged In: YES 
user_id=302801

CVS version seems be ok. This entry looks like a duplicate
of  #667511 (but don't trust me too much :)

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

Comment By: Pavel Hlavnicka (pavel_hlavnicka)
Date: 2003-01-20 09:28

Message:
Logged In: YES 
user_id=302801

Bugs you pointed seem be of the similar flavour. Especially
#667511. 

I'd like to try the CVS version, but my system uses older
version of autoconf, and I have got some reasons not to upgrade.

If you want me to test it, please be so nice, and make a
test distribution for me. Sorry and thanks.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-17 18:40

Message:
Logged In: YES 
user_id=290026

We hava a few fixes for storeRawNames in CVS.
Please check bugs #618199 and #667511 if they explain
the behaviour to you.

Before spending more time on it, I recommend you
run with CVS for a while and check if the problem
shows up again.

I also asked the user who reported these bugs first,
and he thinks your problem may be the same.

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

Comment By: Pavel Hlavnicka (pavel_hlavnicka)
Date: 2003-01-17 18:27

Message:
Logged In: YES 
user_id=302801

I'm using 1.95.5. I didn't check CVS, and would have to
check the source, not execution to prove it. The reason for
it is that the error is really hard to reporoduce.

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

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

Message:
Logged In: YES 
user_id=290026

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

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

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

From noreply at sourceforge.net  Mon Jan 20 08:59:13 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jan 20 11:55:51 2003
Subject: [Expat-bugs] [ expat-Bugs-669861 ] storeRawNames and namespace
	processing
Message-ID: <E18afGT-0004ig-00@sc8-sf-web3.sourceforge.net>

Bugs item #669861, was opened at 2003-01-17 12:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=669861&group_id=10127

Category: None
Group: None
Status: Open
>Resolution: Duplicate
Priority: 5
Submitted By: Pavel Hlavnicka (pavel_hlavnicka)
>Assigned to: Karl Waclawek (kwaclaw)
Summary: storeRawNames and namespace processing

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

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

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

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

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

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

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

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

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

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

Keep a good work

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-20 11:59

Message:
Logged In: YES 
user_id=290026

That's great.

Please let me know if you have any more problems.

If I don't hear from you in the next few days,
I'll close this bug as a duplicate. 

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

Comment By: Pavel Hlavnicka (pavel_hlavnicka)
Date: 2003-01-20 11:00

Message:
Logged In: YES 
user_id=302801

CVS version seems be ok. This entry looks like a duplicate
of  #667511 (but don't trust me too much :)

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

Comment By: Pavel Hlavnicka (pavel_hlavnicka)
Date: 2003-01-20 04:28

Message:
Logged In: YES 
user_id=302801

Bugs you pointed seem be of the similar flavour. Especially
#667511. 

I'd like to try the CVS version, but my system uses older
version of autoconf, and I have got some reasons not to upgrade.

If you want me to test it, please be so nice, and make a
test distribution for me. Sorry and thanks.

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

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

Message:
Logged In: YES 
user_id=290026

We hava a few fixes for storeRawNames in CVS.
Please check bugs #618199 and #667511 if they explain
the behaviour to you.

Before spending more time on it, I recommend you
run with CVS for a while and check if the problem
shows up again.

I also asked the user who reported these bugs first,
and he thinks your problem may be the same.

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

Comment By: Pavel Hlavnicka (pavel_hlavnicka)
Date: 2003-01-17 13:27

Message:
Logged In: YES 
user_id=302801

I'm using 1.95.5. I didn't check CVS, and would have to
check the source, not execution to prove it. The reason for
it is that the error is really hard to reporoduce.

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

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

Message:
Logged In: YES 
user_id=290026

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

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

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

From noreply at sourceforge.net  Mon Jan 20 20:34:07 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jan 20 23:30:45 2003
Subject: [Expat-bugs] 
 [ expat-Bugs-651754 ] Function to get XML_Memory_Handling_Suite
Message-ID: <E18aq6x-0004u1-00@sc8-sf-web4.sourceforge.net>

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

Category: None
Group: Feature Request
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Artyom Bolgar (artyom17)
Assigned to: Nobody/Anonymous (nobody)
Summary: Function to get XML_Memory_Handling_Suite

Initial Comment:
It is not a bug report, it is a feature request. What do 
you think of adding the function, that returns the pointer 
to XML_Memory_Handling_Suite for passed 
XML_Parser? It is necessary for me, I am developing an 
extension for Expat and I would like to use the same 
allocation/reallocation/free function as the current 
XML_Parser uses. Since XML_Parser struct defined 
inside .C-file, I can't get an access to 
XML_Memory_Handling_Suite struct for the parser. 
Please add this function, since it will be very simple.

Sincerely,
 Artyom Bolgar.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-20 23:34

Message:
Logged In: YES 
user_id=3066

Since a sufficient API enhancement has been committed and
documented, this issue is closed.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-16 17:15

Message:
Logged In: YES 
user_id=290026

Applied a patch with two solutions:

1) Added XML_FreeContentModel API
2) Exposed all three memory handling functions as
   XML_MemMalloc, XML_MemRealloc, XML_MemFree

Check out xmlparse.c rev. 1.102 and expat.h rev. 1.50

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-11 16:38

Message:
Logged In: YES 
user_id=290026

Artyom,

I think I understand now.
>From a proper design perspective your use case should
not involve Expat. This is a matter between your code
and the user's application. It should provide you with
the necessary information to use it properly.

However, I still think that there is a reason
for having an API like the one you suggested:

There is one use case where the application has to
free memory allocated by the parser (in the  element 
declaration handler).  If Expat is not accessed from 
C/C++,  then there may not be a way to do so
from languages that can access Dlls, but have different
memory allocation implementations.

In my case, I am lucky that Delphi's memory manager
is basically identical to C/C++, so I can create the
parser with the Delphi memory management functions.

However, I would have preferred if there was an API like 
you suggested, or at least a function to free the content 
model passed to the element declaration handler.

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

Comment By: Artyom Bolgar (artyom17)
Date: 2002-12-11 16:22

Message:
Logged In: YES 
user_id=657326

Karl,
Why user overloads memory allocation functions? Because 
he don't want to use malloc/realloc/free for some reasons, for 
example performance or compatibility (some embedded 
platforms do not support malloc/realloc/free functions). As far 
as I develops the extension of Expat and it will be linked 
together with Expat library I want to use the same memory 
functions as are used by parser.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-11 15:18

Message:
Logged In: YES 
user_id=290026

Artyom:
I am still not clear what you mean with overloading.
I don't think you need the same memory handler 
functions as Expat as long as you don't have to free
memory that Expat allocates.

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

Comment By: Artyom Bolgar (artyom17)
Date: 2002-12-11 15:14

Message:
Logged In: YES 
user_id=657326

I am developing an extension to Expat API that provides 
ability of parsing from any source, from file, network, etc. Of 
course, I have to make some memory allocations. For 
example, the function name EXML_CreateFileInputSource 
(XML_Parser, const char* filename). I don't know how 
XML_Parser was created, with mem suite or without. But I 
need to use the same memory functions as parser uses, 
because user might overload them.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-11 14:40

Message:
Logged In: YES 
user_id=290026

Attached is a potential patch MemSuite.diff.
Includes changes to expat.h, xmlparse.c
and the DEF files for Windows builds.

This is just a suggestion.
For the content model example all one would need,
however, is a FreeContentModel API.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-11 10:23

Message:
Logged In: YES 
user_id=290026

Fred:
I know that, but I just pointed out an example
where it would make sense.

I have another reason too that has to do with
writing wrappers/bindings for Expat, but I will
mention it in a reply to your upcoming message
on expat-discuss.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-12-11 09:38

Message:
Logged In: YES 
user_id=3066

Karl:  Artyom didn't say he was setting a handler on an
XML_Parser object someone else passed him, nor did he say he
wasn't.  The only specific I see here is that he wants to
use the same resource handlers as the parser; it's not clear
that this is a real requirement.  I'll follow up with a
discussion on expat-discuss.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-11 08:59

Message:
Logged In: YES 
user_id=290026

Once you set an element declaration handler you need
to free the content model passed to the handler, so
you will need to know the memory handler in use.

It is just a rare case that the code that sets the handlers
has no control over the code that creates the parser.
But it is not too far fetched, so IMO that feature
request makes some sense, unless I am overlooking
the obvious.

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

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

Message:
Logged In: YES 
user_id=3066

Can you explain why you need the memory handler they've
asked Expat to use?  The requirements aren't clear, so more
explanation of the use case should help.

Thanks.

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

Comment By: Artyom Bolgar (artyom17)
Date: 2002-12-11 06:32

Message:
Logged In: YES 
user_id=657326

Of course, I know about this. But in my case, I use 
XML_Parser passed by user (and it is created by him), and I 
don't know how it was created, either by 
XML_ParserCreate_MM or not. That is why I requested this 
function.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-12-10 21:24

Message:
Logged In: YES 
user_id=290026

Are you creating the parser using XML_ParserCreate?
In that case - without supplying an external memory handler,
Expat just uses the standard C runtime functions
malloc, realloc and free.

If you use XML_ParserCreate_MM however, then *you*
are supplying the memory handler yourself.

In both cases you don't need the requested function.

Is your situation different from what I described?

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

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

From noreply at sourceforge.net  Mon Jan 20 20:39:12 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jan 20 23:35:45 2003
Subject: [Expat-bugs] [ expat-Bugs-667511 ] additional patch for #618199
Message-ID: <E18aqBs-0008BB-00@sc8-sf-web1.sourceforge.net>

Bugs item #667511, was opened at 2003-01-13 20:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=667511&group_id=10127

Category: None
>Group: Test Required
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: additional patch for #618199

Initial Comment:
The attached patch ensures that localPart will point to TAG.buf 
when storeRawNames is called. 
 
There was no need to replace the TAG_NAME.str with the 
keyname for the ELEMENT_TYPE hash entry since the pool 
takes care of deallocating it (keyname) when the pool is 
destroyed. 

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-20 23:39

Message:
Logged In: YES 
user_id=3066

This should be moved to the "Test Required" group, but there
isn't enough information in the report to reproduce the
problem, so I'm closing it instead.

Jeremy, if you are able to provide enough information to
reproduce this, please insist that we re-open this report or
open a new one with the information.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-14 19:57

Message:
Logged In: YES 
user_id=290026

Patch applied in rev. 1.101 of xmlparse.c.

Assigned to Fred for regression testing.
However, no reproducible bug description was supplied by
the author of this bug report.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-14 12:48

Message:
Logged In: YES 
user_id=290026

I looked at storeAtts, and I agree with your assessment.
tag->name.str is always pointing into tag->buf when 
passed to storeAtts() (except for empty elements, but 
for that storeRawnames won't get called).

tag->name.localPart is set to point to tag->name.str 
inside of  storeAtts(). So, if tag->name.str gets 
reassigned inside storeAtts() before assigning it to 
localPart then localPart will not point into tag->buf 
anymore.

I will apply your patch soon.


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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-14 04:16

Message:
Logged In: YES 
user_id=38980

Sorry, I cannot trim a problem to a small test case.  It seems to 
require a certain amount of additional malloc/realloc/free that I 
cannot determine.  I can say that it only happens when doing multiple 
XML_ParseBuffer calls.  Eith debug prints I traced the error to where 
storeRawNames updates the TAG_NAME.localPart.   
 
The problem is that it should only be updated when localPart points 
into tag->buf, which it almost always does.  The exception to this is 
addressed by my patch.  To fix this in storeRawNames would add 
overhead that is not required if TAG_NAME.str is not redefined before 
TAG_NAME.localPart is defined in storeAtts. 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-13 23:05

Message:
Logged In: YES 
user_id=290026

I think you meant to say:

"The attached patch ensures that TAG_NAME.str will point to
TAG.buf when storeRawNames is called."

Your changes make sense to me, but I am not sure
that there is a bug, since TAG_NAME.str doesn't need
to be updated when it does not point to tag->buf.

Is there a specific case where it fails for you?
If yes, would you please give us the details, so that
we can build a regression test for the patch?

Thanks! 




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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-13 21:34

Message:
Logged In: YES 
user_id=38980

Oops... 
Here is the attachment again 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-13 21:06

Message:
Logged In: YES 
user_id=290026

Two things:

- I can't see the attachment
- Does this apply to the current CVS?

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

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

From noreply at sourceforge.net  Mon Jan 20 20:40:29 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jan 20 23:37:00 2003
Subject: [Expat-bugs] [ expat-Bugs-644343 ] (expat 1.95.5) 'const' keyword
Message-ID: <E18aqD7-0008EH-00@sc8-sf-web1.sourceforge.net>

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

Category: None
Group: Feature Request
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Artyom Bolgar (artyom17)
Assigned to: Nobody/Anonymous (nobody)
Summary: (expat 1.95.5) 'const' keyword

Initial Comment:
Not all C-compilers knows the 'const' keyword 
(especially old ones). That is why I propse to add the 
following lines into expat.h file:

#ifndef __cplusplus
#define const
#endif

It defines 'const' as empty identifier and everything is 
compiled OK. I attached the diff file for 1.95.5.
Thanks.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-20 23:40

Message:
Logged In: YES 
user_id=3066

Since "const" is ANSI C and additional information has not
been provided, I'm closing this report.

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

Comment By: Artyom Bolgar (artyom17)
Date: 2002-11-27 20:12

Message:
Logged In: YES 
user_id=657326

Well, I have to check it out to be sure. I'll post an additional 
info later.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-11-27 15:34

Message:
Logged In: YES 
user_id=290026

But is xlc the only C compiler for AIX?
A quick google search turned up:

- IBM C for AIX
- VisualAge C++ for AIX
- gcc (version 2.9.aix51.020209 )
- XL C for AIX (seems to have a C89 compliance option)



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

Comment By: Artyom Bolgar (artyom17)
Date: 2002-11-27 15:14

Message:
Logged In: YES 
user_id=657326

I seem to recall the xlc compiler on the IBM AIX box. 

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-11-26 22:38

Message:
Logged In: YES 
user_id=3066

What C compilers don't support "const"?  That's not exactly a 
recent addition.  Unless you can make the case that there 
are important platforms which can't be supported at all (with 
any compiler) without this, I'll reject it.  It just doesn't make a 
lot of sense to support C implementations that don't comply 
with at least C89.

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

Comment By: Artyom Bolgar (artyom17)
Date: 2002-11-26 16:54

Message:
Logged In: YES 
user_id=657326

More exactly, will be better to change it to:

#ifdef XML_NOCONST
#define const
#endif

I guess.

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

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

From noreply at sourceforge.net  Mon Jan 20 21:05:16 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 21 00:01:40 2003
Subject: [Expat-bugs] [ expat-Bugs-644334 ] (expat 1.95.5) Compiling by aCC on
	HP
Message-ID: <E18aqb6-0001e3-00@sc8-sf-web3.sourceforge.net>

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

Category: Documentation
Group: Platform Specific
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Artyom Bolgar (artyom17)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: (expat 1.95.5) Compiling by aCC on HP

Initial Comment:
I found out that EXPAT can't be compiled by aCC 
compiler on HP and SUN. It happens because this 
compiler tries to compile C-files as C++ ones. That is 
why some lines can't be compiled, for example:

   parser = memsuite->malloc_fcn(sizeof(struct 
XML_ParserStruct));

it should be changed to:

   parser = (struct XML_ParserStruct*)memsuite-
>malloc_fcn(sizeof(struct XML_ParserStruct));

In this case it is compatible with both C and C++ 
languages. There are a lot of such lines in xmlparse.c 
and one in xmltok.c. I fixed all such places and I 
attached the .diff-files for 1.95.5 version. 
This problem could be easyly reproduced by compiling 
by VC6 or VC7 with '-TP' option ("compile all files as 
C++").


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-21 00:05

Message:
Logged In: YES 
user_id=3066

Documented XML_SetExternalEntityRefHandlerArg(), including
API foolishness, in doc/reference.html 1.40.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-11-27 13:10

Message:
Logged In: NO 

Couldn't this problem be simply solved by specifying using 
c89 (not aCC) when compiling?

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-11-27 12:08

Message:
Logged In: YES 
user_id=290026

There were more things to fix, some cosmetic changes,
and I uncovered a problem with the API - the 
externalEntityRefHandler type definition:

This is how the externalEntityRefHandler is called:

if (!externalEntityRefHandler(
                                        externalEntityRefHandlerArg,
                                        0,
                                        entity->base,
                                        entity->systemId,
                                        entity->publicId))

and this is how one sets externalEntityRefHandlerArg:

void
XML_SetExternalEntityRefHandlerArg(
                                      XML_Parser parser, void *arg)
{
  if (arg)
    externalEntityRefHandlerArg = arg;
  else
    externalEntityRefHandlerArg = parser;
}

So, externalEntityRefHandlerArg is a void pointer, but 
can contain a user defined pointer or a parser pointer.
Unfortunately the externalEntityRefHandler is defined 
like this:

typedef int (*XML_ExternalEntityRefHandler)(
                                            XML_Parser parser,
                                            const XML_Char *context,
                                            const XML_Char *base,
                                            const XML_Char *systemId,
                                            const XML_Char *publicId);

In order to fix that I changed the type of
externalEntityRefHandlerArg  from void * to
XML_Parser (= struct struct XML_ParserStruct *)
and added a type cast in 
XML_SetExternalEntityRefHandlerArg.
However, this is not a real fix, since ideally
the API should be changed. Needs documentation.

Attached as xmlparse.diff.

Leave open for Fred to document the API issue.






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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-11-26 23:05

Message:
Logged In: YES 
user_id=3066

Committed changes based on the supplied patch as 
lib/xmlparse.c 1.96 and lib/xmltok.c 1.27.

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

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

From noreply at sourceforge.net  Mon Jan 20 21:07:53 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 21 00:04:16 2003
Subject: [Expat-bugs] [ expat-Bugs-634409 ] XML_Feature HP-UX expat-1.95.5
Message-ID: <E18aqdd-0001jO-00@sc8-sf-web3.sourceforge.net>

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

Category: Build control
Group: Platform Specific
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: XML_Feature HP-UX expat-1.95.5

Initial Comment:
a build of expat-1.95.5.tar.gz on HP-UX 11
fails with

gcc -O2 -w -Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions  -O2 -w 
-I/usr/local/include -I./lib -I. -o xmlwf/xmlwf.o -c
xmlwf/xmlwf.c
xmlwf/xmlwf.c: In function `showVersion':
xmlwf/xmlwf.c:602: syntax error before `*'
xmlwf/xmlwf.c:613: `features' undeclared (first use in
this function)
xmlwf/xmlwf.c:613: (Each undeclared identifier is
reported only once
xmlwf/xmlwf.c:613: for each function it appears in.)
xmlwf/xmlwf.c:613: `XML_FEATURE_END' undeclared (first
use in this function)
make: *** [xmlwf/xmlwf.o] Error 1


No problem on expat-1.95.4.tar.gz and expat-1.95.2.tar.gz

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-21 00:07

Message:
Logged In: YES 
user_id=3066

Since there's no new information or reason to suspect this
was not a user error, I'm closing this as "Works for me".

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-11-20 00:16

Message:
Logged In: YES 
user_id=3066

If this bug can't be confirmed before the 1.95.6 release, it will 
be closed as user-error (old expat.h getting picked up).

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

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

Message:
Logged In: YES 
user_id=3066

The features support was added in 1.95.5.  It looks like
you're picking up an older revision of the expat.h header file.

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

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

From noreply at sourceforge.net  Mon Jan 20 21:09:20 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 21 00:05:44 2003
Subject: [Expat-bugs] [ expat-Bugs-566088 ] php make fails @ libexpat.la on
	OSX
Message-ID: <E18aqf2-0001l4-00@sc8-sf-web3.sourceforge.net>

Bugs item #566088, was opened at 2002-06-08 00:23
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=566088&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: php make fails @ libexpat.la on OSX

Initial Comment:
hi all,

a build of php-latest (php4-200206071800) on OSX Server
10.1.4 with:

./configure --enable-shared --enable-static
--prefix=/usr/local/php4 --with-layout=PHP
--with-apxs2=/usr/local/apache2/sbin/apxs
--with-config-file-path=/private/etc/php4/
--mandir=/usr/local/man
--localstatedir=/private/var/php4
--x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib
--with-expat-dir=/usr/local/expat
--with-mysql=/usr/local/mysql --with-openssl
--with-imap-ssl --with-mcrypt --with-mhash=/usr/local
--with-kerberos --with-imap=/usr/local/imap
--enable-mailparse --enable-magic-quotes --enable-ftp
--enable-force-cgi-redirect --enable-discard-path
--enable-inline-optimization --with-pear --with-zlib
--enable-calendar --disable-safe-mode --with-tsrm-pthreads

fails with:

.o Zend/zend_qsort.o Zend/zend_multibyte.o
Zend/zend_execute.o sapi/apache2filter/sapi_apache2.o
sapi/apache2filter/apache_config.o
sapi/apache2filter/php_functions.o
main/internal_functions.o -lcrypto -lssl -lc-client
-lexpat -lmysqlclient -lmhash -lmcrypt -lltdl -lz -lssl
-lcrypto -lbind -lm -ldl -lgssapi_krb5 -lkrb5
-lk5crypto -lcom_err -ldl -o libs/libphp4.bundle && cp
libs/libphp4.bundle libs/libphp4.so
/usr/bin/ld: warning -L: directory name (/lib) does not
exist
/usr/bin/ld: /usr/local/expat/lib/libexpat.la bad magic
number (not a Mach-O file)
make: *** [libs/libphp4.bundle] Error 1

expat build went fine on OSX, with:

cd expat-1.95.3;
./configure --prefix=/usr/local/expat
--mandir=/usr/local/man --x-include=/usr

to be used by a number of other progrs successfully ......

any thoughts/suggestions on either would be much
appreciated!

fyi, details of my environment are doc'd on my
web-page, below .....

thanks!

richard


--------------------------------------
R Blake
blakers <at> mac.com
http://homepage.mac.com/blakers
--------------------------------------

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-21 00:09

Message:
Logged In: YES 
user_id=3066

Since there's no confirmation that this is an Expat bug, I'm
closing this as "Won't fix".

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

Comment By: Greg Stein (gstein)
Date: 2003-01-03 14:22

Message:
Logged In: YES 
user_id=6501

This may be caused by an old version of libtool being used
to create the tarball. Please try rebuilding the libtool
scripts by running the "buildconf.sh" script found in the
top-level dir of the distribution. Make sure that your OSX
box has the "correct" libtool. (I'm not sure where that can
be found, but I do know that libtool has had problems on OSX)

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

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

From noreply at sourceforge.net  Mon Jan 20 21:16:33 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 21 00:12:57 2003
Subject: [Expat-bugs] [ expat-Bugs-591556 ] Solaris make error
Message-ID: <E18aqm1-0001xA-00@sc8-sf-web3.sourceforge.net>

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

>Category: XML::Parser (inactive)
Group: Platform Specific
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: Solaris make error

Initial Comment:
Receiving this error from the make process of 1.95.4 in 
both Solaris 2.8 and 2.5.1 using gcc and ccs/cc.

make: Fatal error: Don't know how to make 
target 'xmlwf/xmlwf.c'

Here is the Make file that is being generated from 
the ./configure process: 

###############################################
#################
# Process this file with top-level configure script to 
produce Makefile
#
# Copyright 2000 Clark Cooper
#
#  This file is part of EXPAT.
#
#  EXPAT is free software; you can redistribute it and/or 
modify it
#  under the terms of the License (based on the MIT/X 
license) contained
#  in the file COPYING that comes with this distribution.
#
# EXPAT IS PROVIDED "AS IS", WITHOUT 
WARRANTY OF ANY KIND,
# EXPRESS OR IMPLIED, INCLUDING BUT NOT 
LIMITED TO THE WARRANTIES OF
# MERCHANTABILITY, FITNESS FOR A PARTICULAR 
PURPOSE AND NONINFRINGEMENT.
# IN NO EVENT SHALL THE AUTHORS OR 
COPYRIGHT HOLDERS BE LIABLE FOR ANY
# CLAIM, DAMAGES OR OTHER LIABILITY, 
WHETHER IN AN ACTION OF CONTRACT,
# TORT OR OTHERWISE, ARISING FROM, OUT OF 
OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN 
EXPAT.
#

SHELL = /bin/bash

srcdir = .
top_srcdir = .


prefix = /usr/local
exec_prefix = ${prefix}

bindir = ${exec_prefix}/bin
libdir = ${exec_prefix}/lib
includedir = ${prefix}/include
mandir = ${prefix}/man/man1

top_builddir = .


INSTALL = conftools/install-sh -c
INSTALL_PROGRAM = ${INSTALL}
INSTALL_DATA = ${INSTALL} -m 644
mkinstalldirs = $(SHELL) 
$(top_srcdir)/conftools/mkinstalldirs

MANFILE = $(srcdir)/doc/xmlwf.1
APIHEADER = $(srcdir)/lib/expat.h
LIBRARY = libexpat.la


default:  buildlib xmlwf/xmlwf

buildlib: $(LIBRARY)

all: $(LIBRARY) xmlwf/xmlwf examples/elements 
examples/outline

clean:
	cd lib && rm -f $(LIBRARY) *.o *.lo && rm -
rf .libs _libs
	cd xmlwf && rm -f xmlwf *.o *.lo && rm -
rf .libs _libs
	cd examples && rm -f elements outline *.o 
*.lo && rm -rf .libs _libs
	find . -name core | xargs rm -f

distclean: clean
	rm -f expat_config.h config.status config.log 
config.cache libtool
	rm -f Makefile

extraclean: distclean
	rm -f expat_config.h.in configure
	rm -f conftools/ltconfig conftools/ltmain.sh 
conftools/libtool.m4

check: tests/runtests
	tests/runtests

install: xmlwf/xmlwf installlib
	$(mkinstalldirs) $(bindir) $(mandir)
	$(LIBTOOL) --mode=install 
$(INSTALL_PROGRAM) xmlwf/xmlwf $(bindir)/xmlwf
	$(INSTALL_DATA) $(MANFILE) $(mandir)

installlib: $(LIBRARY) $(APIHEADER)
	$(mkinstalldirs) $(libdir) $(includedir)
	$(LIBTOOL) --mode=install $(INSTALL) 
$(LIBRARY) $(libdir)/$(LIBRARY)
	$(INSTALL_DATA) $(APIHEADER) 
$(includedir)

uninstall: uninstalllib
	$(LIBTOOL) --mode=uninstall rm -f 
$(bindir)/xmlwf
	rm -f $(mandir)/xmlwf.1

uninstalllib:
	$(LIBTOOL) --mode=uninstall rm -f $(libdir)/
$(LIBRARY)
	rm -f $(includedir)/$(APIHEADER)

# for VPATH builds (invoked by configure)
mkdir-init:
	@for d in lib xmlwf examples tests ; do \
		(mkdir $$d 2> /dev/null || test 1) ; \
	done

CC = gcc
LIBTOOL = $(SHELL) $(top_builddir)/libtool

INCLUDES = -I$(srcdir)/lib -I.
LDFLAGS = 
CPPFLAGS = 
CFLAGS = -g -O2 -Wall -Wmissing-prototypes -Wstrict-
prototypes -fexceptions
VSNFLAG = -version-info 3:0:3

### autoconf this?
LTFLAGS = --silent

COMPILE = $(CC) $(CFLAGS) $(DEFS) $(CPPFLAGS) 
$(INCLUDES)
LTCOMPILE = $(LIBTOOL) $(LTFLAGS) --
mode=compile $(COMPILE)
LINK_LIB = $(LIBTOOL) $(LTFLAGS) --mode=link 
$(COMPILE) -no-undefined $(VSNFLAG) -rpath $(libdir) 
$(LDFLAGS) -o $@
LINK_EXE = $(LIBTOOL) $(LTFLAGS) --mode=link 
$(COMPILE) $(LDFLAGS) -o $@

LIB_OBJS = lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo
$(LIBRARY): $(LIB_OBJS)
	$(LINK_LIB) $(LIB_OBJS)

lib/xmlparse.lo: lib/xmlparse.c lib/expat.h lib/xmlrole.h 
lib/xmltok.h \
	$(top_builddir)/expat_config.h

lib/xmlrole.lo: lib/xmlrole.c lib/ascii.h lib/xmlrole.h \
	$(top_builddir)/expat_config.h

lib/xmltok.lo: lib/xmltok.c lib/xmltok_impl.c 
lib/xmltok_ns.c \
	lib/ascii.h lib/asciitab.h lib/iasciitab.h 
lib/latin1tab.h \
	lib/nametab.h lib/utf8tab.h lib/xmltok.h 
lib/xmltok_impl.h \
	$(top_builddir)/expat_config.h


XMLWF_OBJS = xmlwf/xmlwf.o xmlwf/xmlfile.o 
xmlwf/codepage.o xmlwf/unixfilemap.o
xmlwf/xmlwf.o: xmlwf/xmlwf.c
xmlwf/xmlfile.o: xmlwf/xmlfile.c
xmlwf/codepage.o: xmlwf/codepage.c
xmlwf/unixfilemap.o: xmlwf/unixfilemap.c
xmlwf/xmlwf: $(XMLWF_OBJS) $(LIBRARY)
	$(LINK_EXE) $(XMLWF_OBJS) $(LIBRARY)

examples/elements.o: examples/elements.c
examples/elements: examples/elements.o $(LIBRARY)
	$(LINK_EXE) $< $(LIBRARY)

examples/outline.o: examples/outline.c
examples/outline: examples/outline.o $(LIBRARY)
	$(LINK_EXE) $< $(LIBRARY)

tests/chardata.o: tests/chardata.c tests/chardata.h
tests/runtests.o: tests/runtests.c tests/chardata.h
tests/runtests: tests/runtests.o tests/chardata.o 
$(LIBRARY)
	$(LINK_EXE) $^ -lcheck

tests/xmltest.zip:
	cd tests && wget 
ftp://ftp.jclark.com/pub/xml/xmltest.zip

tests/xmltest: tests/xmltest.zip
	cd tests && unzip -q xmltest.zip

run-xmltest: xmlwf/xmlwf tests/xmltest
	tests/xmltest.sh

.SUFFIXES: .c .lo .o

.c.o:
	$(COMPILE) -o $@ -c $<
.c.lo:
	$(LTCOMPILE) -o $@ -c $<

.PHONY: buildlib all \
	clean distclean extraclean maintainer-clean \
	dist distdir \
	install uninstall


Any help would be greatly appreciated.


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-21 00:16

Message:
Logged In: YES 
user_id=3066

This may be an XML::Parser problem, or it might be a problem
building using non-GNU make on this platform, but it's
definately a build-process issue for an older version of
Expat.  Since the build process has changed a fair bit
(though not so much as for some older releases), I'm closing
this as out-of-date.

If this can be reproduced using the 1.95.5 release or the
CVS version of the code, please open a new report.  Include
all error output.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-09-10 11:22

Message:
Logged In: NO 

An answer to zhangy@zhangy, although this is not a right place
for one. Sorry...

You seem to be using GCC on Solaris. /usr/ucb/cc is just a
wrapper script made by Sun which tries to find Sun's C
compiler. I know almost nothing about Perl and its libraries
(and I think that you know almost nothing about Solaris,
he-he ;), but I suggest you to make Perl configuration
script use 'gcc' instead of 'cc'.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-09-09 18:33

Message:
Logged In: NO 

Hello, Sir,
I run into a make problem on Solaris 8.

system info:[24] 


zhangy@zhangy: uname -a
SunOS zhangy 5.8 Generic_108528-13 sun4u sparc
SUNW,Ultra-5_10

I download the perl module XML::Parser (version 2.31,
released on  from 
www.cpan.org. 


Before I install above module, I install expat first.

I download expat module from
http://sourceforge.net/project/expat/ and put the 
file under directory

/home/zhangy/perl/module/ 

then unzip the file: 

gzip -d  .gz expat-1.95.5.tar

then 

tar -xvf expat-1.95.5.tar

then
 
under directory  /home/zhangy/perl/module/expat-1.95.5/
do the following:


1) type from prompt:

./configure --prefix=/home/zhangy/perl/perlxml/    
CC=/net/bandsaw2/tools/on81-tools/SUNWspro/SC6.1-new/bin/cc
     

2) type from prompt
   make

3) type from prompt
   make install

so far so good.


Then I begin to install XML::Parser

under directory:

/home/zhangy/perl/module/XML-Parser-2.31/

from prompt type:

perl Makefile.PL PREFIX=/home/zhangy/perl INSTALLDIRS=module 
                  
EXPATLIBPATH=/home/zhangy/perl/perlxml/lib 
                  
EXPATINCPATH=/home/zhangy/perl/perlxml/include/

It shows:

Writing Makefile for XML::Parser::Expat
Writing Makefile for XML::Parser


SO FAR SO GOOD.


Then still under dir 
/home/zhangy/perl/module/XML-Parser-2.31/

from prompt type:

make


it shows:

********************************************************************
[51] zhangy@zhangy: make
cc -c -I/home/zhangy/perl/perlxml/include/  -xO3
-xdepend     -DVERSION=\2.31\ 
 -DXS_VERSION=\2.31\ -KPIC
-I/usr/perl5/5.00503/sun4-solaris/CORE  Expat.c
/usr/ucb/cc:  language optional software package not
installed
*** Error code 1
make: Fatal error: Command failed for target `Expat.o'
Current working directory
/home/zhangy/perl/module/XML-Parser-2.31/Expat
*** Error code 1
make: Fatal error: Command failed for target `subdirs'
*******************************************************************

So what is wrong for the installation?  Where do I get the 
"language optional software package" that is not installed?


Thanks for help.



Charlie


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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-31 09:26

Message:
Logged In: NO 

Are you using Sun's make? This isn't a wise thing when you are
working with autoconf-generated stuff  --  and you are!

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

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

From noreply at sourceforge.net  Mon Jan 20 21:24:57 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 21 00:21:37 2003
Subject: [Expat-bugs] [ expat-Bugs-658080 ] Request a link on reentrancy
Message-ID: <E18aqu9-0007Nn-00@sc8-sf-web2.sourceforge.net>

Bugs item #658080, was opened at 2002-12-23 21:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=658080&group_id=10127

Category: Documentation
Group: Feature Request
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Doug Ransom (dougransom)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Request a link on reentrancy

Initial Comment:
I have described a technique that can be used to make a
reentrant parser in C or C++ with expat.

http://www.codepedia.com/wiki/display.aspx?WikiID=1&pagename=thunks

The technique is general, but I was inspired to write
the article by the expat interface.

I request a link to it so people know expat doesn't
need to me modified to make a reentrant parser for
mulitthreaded programming.  They can also get rid of
global variables in any expat parser, even if they are
building a DOM.







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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-21 00:24

Message:
Logged In: YES 
user_id=3066

Added a link to the website in htdocs/index.html revision 1.35.

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

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

From noreply at sourceforge.net  Mon Jan 20 21:31:13 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 21 00:27:53 2003
Subject: [Expat-bugs] 
 [ expat-Bugs-626001 ] ld: Mismatched ABI (not an ELF file) for
Message-ID: <E18ar0D-0007cG-00@sc8-sf-web2.sourceforge.net>

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

Category: Build control
Group: None
Status: Open
Resolution: None
>Priority: 5
Submitted By: Sanjay (sanjaywaza)
Assigned to: Greg Stein (gstein)
Summary: ld: Mismatched ABI (not an ELF file) for

Initial Comment:
I tried to install the expat1.95.4) on HP-UX 11.0 (64 Bit).
Then I tried to build XML::Parser2.31.1 and I am getting 
the error (ld: Mismatched ABI (not an ELF file). 
I am getting the following error during 
make . 
 
cp Parser/Encodings/README 
blib/lib/XML/Parser/Encodings/README 
cp Parser/Encodings/x-sjis-cp932.enc 
blib/lib/XML/Parser/Encodings/x-sjis-cp932.enc 
cp Parser/Encodings/iso-8859-7.enc 
blib/lib/XML/Parser/Encodings/iso-8859-7.enc 
cp Parser/Encodings/big5.enc 
blib/lib/XML/Parser/Encodings/big5.enc 
cp Parser/Encodings/windows-1250.enc 
blib/lib/XML/Parser/Encodings/windows-1250.enc 
cp Parser/Encodings/iso-8859-8.enc 
blib/lib/XML/Parser/Encodings/iso-8859-8.enc 
cp Parser/Encodings/iso-8859-2.enc 
blib/lib/XML/Parser/Encodings/iso-8859-2.enc 
cp Parser/Encodings/x-euc-jp-jisx0221.enc 
blib/lib/XML/Parser/Encodings/x-euc-jp-jisx0221.enc 
cp Parser/Encodings/iso-8859-9.enc 
blib/lib/XML/Parser/Encodings/iso-8859-9.enc 
cp Parser/Encodings/x-sjis-unicode.enc 
blib/lib/XML/Parser/Encodings/x-sjis-unicode.enc 
cp Parser/Encodings/iso-8859-3.enc 
blib/lib/XML/Parser/Encodings/iso-8859-3.enc 
cp Parser/Encodings/x-sjis-jdk117.enc 
blib/lib/XML/Parser/Encodings/x-sjis-jdk117.enc 
cp Parser/Encodings/euc-kr.enc 
blib/lib/XML/Parser/Encodings/euc-kr.enc 
cp Parser/Encodings/iso-8859-4.enc 
blib/lib/XML/Parser/Encodings/iso-8859-4.enc 
cp Parser/Encodings/Japanese_Encodings.msg 
blib/lib/XML/Parser/Encodings/Japanese_Encodings.msg 
cp Parser/Encodings/x-sjis-jisx0221.enc 
blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc 
cp Parser.pm blib/lib/XML/Parser.pm 
cp Parser/Encodings/iso-8859-5.enc 
blib/lib/XML/Parser/Encodings/iso-8859-5.enc 
cp Parser/Encodings/x-euc-jp-unicode.enc 
blib/lib/XML/Parser/Encodings/x-euc-jp-unicode.enc 
cp Parser/LWPExternEnt.pl 
blib/lib/XML/Parser/LWPExternEnt.pl 
cp Expat.pm ../blib/lib/XML/Parser/Expat.pm 
/bin/perl -I/opt/perl5.6.1/lib/5.6.1/PA-RISC2.0 - 
I/opt/perl5.6.1/lib/5.6.1 /opt/perl5.6.1/lib/5.6.1/ExtUtils/x
s 
ubpp -noprotc 
cc -c +z -D_HPUX_SOURCE +DD64 -Ae - 
I/usr/local/include -D_LARGEFILE_SOURCE - 
D_FILE_OFFSET_BITS=64 -O -DVERSION=\2.31\c 
Running Mkbootstrap for XML::Parser::Expat () 
chmod 644 Expat.bs 
rm -f ../blib/arch/auto/XML/Parser/Expat/Expat.sl 
LD_RUN_PATH="/usr/local/lib" /usr/bin/ld -b 
+vnocompatwarnings -L/usr/local/lib -L/lib/pa20_64 
Expat.o -o ../blib/arch/au 
ld: Mismatched ABI (not an ELF file) for -lexpat 
Fatal error. 
*** Error exit code 1 

Stop. 
*** Error exit code 1 

Thanks 
 


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-21 00:31

Message:
Logged In: YES 
user_id=3066

Dropping priority substantially.  This is an HP-UX bug;
someone who can help on that platform needs to figure this
out; the current crop of contributors doesn't seem to
include anyone with knowledge or information about that
platform, and the report doesn't make it clear that this
isn't an XML::Parser problem (XML::Parser is *not* part of
Expat, nor is it provided by the Expat project).

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

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

Message:
Logged In: YES 
user_id=3066

This looks like a build issue to me; I don't know anything about HP-UX, so I 
might be wrong.

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

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

From noreply at sourceforge.net  Tue Jan 21 07:55:32 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 21 10:52:09 2003
Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault: bad API/callback
	interaction
Message-ID: <E18b0kO-0005zs-00@sc8-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: segfault: bad API/callback interaction

Initial Comment:
There is a bad interaction between the call to the
start element handler and the Expat API:  After the
presence of the callback is checked, the addBinding()
function can call XML_SetStartElementHandler(parser,
NULL), after which doContent() will still attempt to
call the start element handler.  This results in a call
to the NULL address, resulting in a memory fault.

This is unlikely to be an issue for applications
written entirely in C, but can reasonably happen when a
wrapper library clears callbacks when an error
condition or exception has been detected.

I've attached a patch and a regression test for this case.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 10:55

Message:
Logged In: YES 
user_id=290026

I had another look and this looks trickier than I thought.
I suggest we add documentation that states that
the start/endNamespaceDeclHandlers will not be called
when the startElementHandler is not set.

I'll post more details in a follow-up.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-10-08 13:40

Message:
Logged In: YES 
user_id=290026

I am not *that* eager <g>.
You take care of it.

Thanks!

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-10-08 13:36

Message:
Logged In: YES 
user_id=3066

Original patch checked in as lib/xmlparse.c 1.92 and
tests/runtests.c 1.36, before I saw Karl's comments.

Karl:  Yes, we should probably fix things so the namespace
decl handlers can be set independently, as the API suggests.
 I can take care of this, unless you beat me to it.  ;-)

Don't know that it warrants a separate issue report, so I'll
leave this one as fixed but open for now.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-10-08 13:21

Message:
Logged In: YES 
user_id=290026

Yes, verified. To be precise, addBinding() can call back
to startNamespaceDeclHandler() which then allows
the application to clear the startElementHandler.

One comment: storeAtts() is called like this

  if (startElementHandler) {
    result = storeAtts(parser, ...);
    ...
  }

presumably because the attributes should only be
stored if needed for the startElementHandler.
However, storeAtts does double duty by also
processing namespace declarations and calling
startNamespaceDeclHandler().

So, if that handler is set, should then not storeAtts()
be called like this:

  if (startElementHandler || startNamespaceDeclHandler)
  {
    result = storeAtts(parser, ...);
    ...
  }

And, if true, one should then apply this logic to the
other occasions when storeAtts() is called.

Or does it not make sense to set 
startNamespaceDeclHandler when
startElementHandler is cleared?



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

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

From noreply at sourceforge.net  Tue Jan 21 08:14:01 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 21 11:10:29 2003
Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault: bad API/callback
	interaction
Message-ID: <E18b12H-0006rm-00@sc8-sf-web4.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: segfault: bad API/callback interaction

Initial Comment:
There is a bad interaction between the call to the
start element handler and the Expat API:  After the
presence of the callback is checked, the addBinding()
function can call XML_SetStartElementHandler(parser,
NULL), after which doContent() will still attempt to
call the start element handler.  This results in a call
to the NULL address, resulting in a memory fault.

This is unlikely to be an issue for applications
written entirely in C, but can reasonably happen when a
wrapper library clears callbacks when an error
condition or exception has been detected.

I've attached a patch and a regression test for this case.


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-21 11:14

Message:
Logged In: YES 
user_id=3066

Added notes about the limitation in the documentation:
doc/reference.html 1.41

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 10:55

Message:
Logged In: YES 
user_id=290026

I had another look and this looks trickier than I thought.
I suggest we add documentation that states that
the start/endNamespaceDeclHandlers will not be called
when the startElementHandler is not set.

I'll post more details in a follow-up.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-10-08 13:40

Message:
Logged In: YES 
user_id=290026

I am not *that* eager <g>.
You take care of it.

Thanks!

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-10-08 13:36

Message:
Logged In: YES 
user_id=3066

Original patch checked in as lib/xmlparse.c 1.92 and
tests/runtests.c 1.36, before I saw Karl's comments.

Karl:  Yes, we should probably fix things so the namespace
decl handlers can be set independently, as the API suggests.
 I can take care of this, unless you beat me to it.  ;-)

Don't know that it warrants a separate issue report, so I'll
leave this one as fixed but open for now.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-10-08 13:21

Message:
Logged In: YES 
user_id=290026

Yes, verified. To be precise, addBinding() can call back
to startNamespaceDeclHandler() which then allows
the application to clear the startElementHandler.

One comment: storeAtts() is called like this

  if (startElementHandler) {
    result = storeAtts(parser, ...);
    ...
  }

presumably because the attributes should only be
stored if needed for the startElementHandler.
However, storeAtts does double duty by also
processing namespace declarations and calling
startNamespaceDeclHandler().

So, if that handler is set, should then not storeAtts()
be called like this:

  if (startElementHandler || startNamespaceDeclHandler)
  {
    result = storeAtts(parser, ...);
    ...
  }

And, if true, one should then apply this logic to the
other occasions when storeAtts() is called.

Or does it not make sense to set 
startNamespaceDeclHandler when
startElementHandler is cleared?



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

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

From karl at waclawek.net  Tue Jan 21 11:12:46 2003
From: karl at waclawek.net (Karl Waclawek)
Date: Tue Jan 21 11:12:53 2003
Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault: bad
	API/callbackinteraction
References: <E18b0kO-0005zs-00@sc8-sf-web2.sourceforge.net>
Message-ID: <003a01c2c167$ef5eb9b0$9e539696@citkwaclaww2k>

Here is the follow-up I promised:

Let's say we try to fix the problem that calling the nameSpaceDeclHandlers
depends on startElementHandler being set, since this means: storeAtts will
be called with tagNamePtr and bindingsPtr not NULL, which will cause
namespace declarations to be processed.

Here is an attempt (abbreviated):

    case XML_TOK_START_TAG_WITH_ATTS:
      haveElmHandlers = startElementHandler || startNamespaceDeclHandler
        || endNamespaceDeclHandler;
      if (!haveElmHandlers) {
        enum XML_Error result = storeAtts(parser, enc, s, 0, 0);
        if (result)
          return result;
      }
      /* fall through */
    case XML_TOK_START_TAG_NO_ATTS:
      {
        ... <lots of stuff cut>
        tag->name.str = (XML_Char *)tag->buf;
        *toPtr = XML_T('\0');
        if (haveElmHandlers) {
          result = storeAtts(parser, enc, s, &(tag->name), &(tag->bindings));
          if (result)
            return result;
          if (startElementHandler)
            startElementHandler(handlerArg, tag->name.str,
                                (const XML_Char **)atts);
        }
        else if (defaultHandler)
          reportDefault(parser, enc, s, next);
        poolClear(&tempPool);
        break;
      }

What if in the startNamespaceDeclHandler (called from storeAtts) we reset the
startElementHandler or the endNamespaceDeclHandler?
What happens in those cases with calling the defaultHandler?

Maybe the defaultHandler is only a substitute for the startElementHandler here?
So then it should look like this:

    case XML_TOK_START_TAG_NO_ATTS:
      {
        ... <lots of stuff cut>
        tag->name.str = (XML_Char *)tag->buf;
        *toPtr = XML_T('\0');
        if (haveElmHandlers) {
          result = storeAtts(parser, enc, s, &(tag->name), &(tag->bindings));
          if (result)
            return result;
          if (startElementHandler)
            startElementHandler(handlerArg, tag->name.str,
                                (const XML_Char **)atts);
          else if (defaultHandler)
            reportDefault(parser, enc, s, next);
        }
        else if (defaultHandler)
          reportDefault(parser, enc, s, next);
        poolClear(&tempPool);
        break;
      }

Any opinions?

Karl



----- Original Message ----- 
From: "SourceForge.net" <noreply@sourceforge.net>
To: <noreply@sourceforge.net>
Sent: Tuesday, January 21, 2003 10:55 AM
Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault: bad API/callbackinteraction


> Bugs item #620343, was opened at 2002-10-08 12:50
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620343&group_id=10127
> 
> Category: None
> Group: None
> Status: Open
> Resolution: Fixed
> Priority: 5
> Submitted By: Fred L. Drake, Jr. (fdrake)
> Assigned to: Fred L. Drake, Jr. (fdrake)
> Summary: segfault: bad API/callback interaction
> 
> Initial Comment:
> There is a bad interaction between the call to the
> start element handler and the Expat API:  After the
> presence of the callback is checked, the addBinding()
> function can call XML_SetStartElementHandler(parser,
> NULL), after which doContent() will still attempt to
> call the start element handler.  This results in a call
> to the NULL address, resulting in a memory fault.
> 
> This is unlikely to be an issue for applications
> written entirely in C, but can reasonably happen when a
> wrapper library clears callbacks when an error
> condition or exception has been detected.
> 
> I've attached a patch and a regression test for this case.
> 
> 
> ----------------------------------------------------------------------
> 
> >Comment By: Karl Waclawek (kwaclaw)
> Date: 2003-01-21 10:55
> 
> Message:
> Logged In: YES 
> user_id=290026
> 
> I had another look and this looks trickier than I thought.
> I suggest we add documentation that states that
> the start/endNamespaceDeclHandlers will not be called
> when the startElementHandler is not set.
> 
> I'll post more details in a follow-up.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Karl Waclawek (kwaclaw)
> Date: 2002-10-08 13:40
> 
> Message:
> Logged In: YES 
> user_id=290026
> 
> I am not *that* eager <g>.
> You take care of it.
> 
> Thanks!
> 
> ----------------------------------------------------------------------
> 
> Comment By: Fred L. Drake, Jr. (fdrake)
> Date: 2002-10-08 13:36
> 
> Message:
> Logged In: YES 
> user_id=3066
> 
> Original patch checked in as lib/xmlparse.c 1.92 and
> tests/runtests.c 1.36, before I saw Karl's comments.
> 
> Karl:  Yes, we should probably fix things so the namespace
> decl handlers can be set independently, as the API suggests.
>  I can take care of this, unless you beat me to it.  ;-)
> 
> Don't know that it warrants a separate issue report, so I'll
> leave this one as fixed but open for now.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Karl Waclawek (kwaclaw)
> Date: 2002-10-08 13:21
> 
> Message:
> Logged In: YES 
> user_id=290026
> 
> Yes, verified. To be precise, addBinding() can call back
> to startNamespaceDeclHandler() which then allows
> the application to clear the startElementHandler.
> 
> One comment: storeAtts() is called like this
> 
>   if (startElementHandler) {
>     result = storeAtts(parser, ...);
>     ...
>   }
> 
> presumably because the attributes should only be
> stored if needed for the startElementHandler.
> However, storeAtts does double duty by also
> processing namespace declarations and calling
> startNamespaceDeclHandler().
> 
> So, if that handler is set, should then not storeAtts()
> be called like this:
> 
>   if (startElementHandler || startNamespaceDeclHandler)
>   {
>     result = storeAtts(parser, ...);
>     ...
>   }
> 
> And, if true, one should then apply this logic to the
> other occasions when storeAtts() is called.
> 
> Or does it not make sense to set 
> startNamespaceDeclHandler when
> startElementHandler is cleared?
> 
> 
> 
> ----------------------------------------------------------------------
> 
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620343&group_id=10127
> 
> _______________________________________________
> Expat-bugs mailing list
> Expat-bugs@libexpat.org
> http://mail.libexpat.org/mailman/listinfo/expat-bugs
>

From noreply at sourceforge.net  Tue Jan 21 08:26:35 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 21 11:23:04 2003
Subject: [Expat-bugs] [ expat-Bugs-664541 ] check.h should be tested by
	configure
Message-ID: <E18b1ER-0005fC-00@sc8-sf-web1.sourceforge.net>

Bugs item #664541, was opened at 2003-01-08 13:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=664541&group_id=10127

Category: Build control
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Ed Avis (epaepa)
Assigned to: Greg Stein (gstein)
Summary: check.h should be tested by configure

Initial Comment:
The presence of the check library (and check.h) should
be checked by 'configure', and if it's not there then
'make check' should print a warning.  Otherwise you get
some rather alarming errors seeming to come from the
test suite :-(.

(expat-1.95.5)

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-21 11:26

Message:
Logged In: YES 
user_id=3066

Bumped priority since this bites a lot of users; the noise
level when the check library is not installed is high enough
to lead someone to think that something is seriously wrong.

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

Comment By: Greg Stein (gstein)
Date: 2003-01-08 19:20

Message:
Logged In: YES 
user_id=6501

Good idea. This shouldn't be too hard at all. Thx.

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

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

From noreply at sourceforge.net  Tue Jan 21 08:59:17 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 21 11:55:52 2003
Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault: bad API/callback
	interaction
Message-ID: <E18b1k5-00082x-00@sc8-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: segfault: bad API/callback interaction

Initial Comment:
There is a bad interaction between the call to the
start element handler and the Expat API:  After the
presence of the callback is checked, the addBinding()
function can call XML_SetStartElementHandler(parser,
NULL), after which doContent() will still attempt to
call the start element handler.  This results in a call
to the NULL address, resulting in a memory fault.

This is unlikely to be an issue for applications
written entirely in C, but can reasonably happen when a
wrapper library clears callbacks when an error
condition or exception has been detected.

I've attached a patch and a regression test for this case.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 11:59

Message:
Logged In: YES 
user_id=290026

I have attached a patch (ElmHandlers.diff) that calls
storeAtts whenever any of the attribute related handlers
is called, i.e. :
- startElmHandler, 
- startNamespaceDeclHandler, and
- endNamespaceDeclHandler.

The default handler calls are adjusted appropriately.

This patch should make it possible to have the 
namespace declaration handlers called even when 
no startElementHandlers is set.

Please review. Not tested yet.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-21 11:14

Message:
Logged In: YES 
user_id=3066

Added notes about the limitation in the documentation:
doc/reference.html 1.41

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 10:55

Message:
Logged In: YES 
user_id=290026

I had another look and this looks trickier than I thought.
I suggest we add documentation that states that
the start/endNamespaceDeclHandlers will not be called
when the startElementHandler is not set.

I'll post more details in a follow-up.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-10-08 13:40

Message:
Logged In: YES 
user_id=290026

I am not *that* eager <g>.
You take care of it.

Thanks!

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-10-08 13:36

Message:
Logged In: YES 
user_id=3066

Original patch checked in as lib/xmlparse.c 1.92 and
tests/runtests.c 1.36, before I saw Karl's comments.

Karl:  Yes, we should probably fix things so the namespace
decl handlers can be set independently, as the API suggests.
 I can take care of this, unless you beat me to it.  ;-)

Don't know that it warrants a separate issue report, so I'll
leave this one as fixed but open for now.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-10-08 13:21

Message:
Logged In: YES 
user_id=290026

Yes, verified. To be precise, addBinding() can call back
to startNamespaceDeclHandler() which then allows
the application to clear the startElementHandler.

One comment: storeAtts() is called like this

  if (startElementHandler) {
    result = storeAtts(parser, ...);
    ...
  }

presumably because the attributes should only be
stored if needed for the startElementHandler.
However, storeAtts does double duty by also
processing namespace declarations and calling
startNamespaceDeclHandler().

So, if that handler is set, should then not storeAtts()
be called like this:

  if (startElementHandler || startNamespaceDeclHandler)
  {
    result = storeAtts(parser, ...);
    ...
  }

And, if true, one should then apply this logic to the
other occasions when storeAtts() is called.

Or does it not make sense to set 
startNamespaceDeclHandler when
startElementHandler is cleared?



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

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

From noreply at sourceforge.net  Tue Jan 21 11:21:39 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 21 14:18:15 2003
Subject: [Expat-bugs] [ expat-Bugs-569461 ] 1.95.3 and new OASIS xml test
	suite
Message-ID: <E18b3xr-0007aD-00@sc8-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: Accepted
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: 2003-01-21 14:21

Message:
Logged In: YES 
user_id=290026

For comparison purposes, I ran the xmltest.sh test script
against release 1.95.5. The results are attached as
TestResults_1_95_5.txt.

Discussion of results:

There are many cases were "output differs"is reported,
but these are due to xmlwf having a different definition
of "canonical XML" than used in the test suite.

Leaving these out, and those that were discussed 
already in this thread, we have the following errors 
reported:
(Note: the two test cases 
          ibm/not-wf/P32/ibm32n09.xml and
          ibm/not-wf/P68/ibm68n06.xml
          are not reported anymore by the script)

* In ibm/invalid/P49/: ibm49i02.xml:7:1: error in 
   processing external entity reference:
   The associated DTD file does not exist - an error
   in the test suite.

The next three documents are not UTF-8 encoded,
and do not have an XML declaration, so Expat rejects 
them, which is correct. An error in the test suite.

* In xmltest/valid/sa/: 049.xml:2:0: not well-formed 
   (invalid token)
* In xmltest/valid/sa/: 050.xml:2:0: not well-formed 
   (invalid token)
* In xmltest/valid/sa/: 051.xml:2:0: not well-formed 
   (invalid token)

The next two documents are classified as invalid,
but well-formed, but they contain faulty UTF-16 
encoding, so they should be classified as not
well-formed. Expat seems correct here.

* In sun/invalid/: utf16b.xml:2:0: not well-formed 
   (invalid token)
* In sun/invalid/: utf16l.xml:1:40: not well-formed 
   (invalid token)

The next three are not marked as why they should fail, 
so the script thinks they are not well-formed, but in
fact they are:

* Well formed: oasis/p06fail1.xml
* Well formed: oasis/p08fail1.xml
* Well formed: oasis/p08fail2.xml

So, no new test case errors have really been added
for release 1.95.5.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-19 14:01

Message:
Logged In: YES 
user_id=290026

Just a comment:
This bug report will likely stay open until Expat passes the
OASIS test suite without any problem at all.
Since no parser currently achieves this, there is a good
chance this bug report will stay open for a long time to come..


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

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 at sourceforge.net  Tue Jan 21 11:32:33 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 21 14:29:18 2003
Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault: bad API/callback
	interaction
Message-ID: <E18b48P-00084q-00@sc8-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: segfault: bad API/callback interaction

Initial Comment:
There is a bad interaction between the call to the
start element handler and the Expat API:  After the
presence of the callback is checked, the addBinding()
function can call XML_SetStartElementHandler(parser,
NULL), after which doContent() will still attempt to
call the start element handler.  This results in a call
to the NULL address, resulting in a memory fault.

This is unlikely to be an issue for applications
written entirely in C, but can reasonably happen when a
wrapper library clears callbacks when an error
condition or exception has been detected.

I've attached a patch and a regression test for this case.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 14:32

Message:
Logged In: YES 
user_id=290026

The patch passes the OASIS test-suite correctly, but
I am not sure it is worth the extra CPU cycles to make
the namespace declaration handlers truly independent
of the startElementHandler.

Any use cases for that?

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 11:59

Message:
Logged In: YES 
user_id=290026

I have attached a patch (ElmHandlers.diff) that calls
storeAtts whenever any of the attribute related handlers
is called, i.e. :
- startElmHandler, 
- startNamespaceDeclHandler, and
- endNamespaceDeclHandler.

The default handler calls are adjusted appropriately.

This patch should make it possible to have the 
namespace declaration handlers called even when 
no startElementHandlers is set.

Please review. Not tested yet.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-21 11:14

Message:
Logged In: YES 
user_id=3066

Added notes about the limitation in the documentation:
doc/reference.html 1.41

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 10:55

Message:
Logged In: YES 
user_id=290026

I had another look and this looks trickier than I thought.
I suggest we add documentation that states that
the start/endNamespaceDeclHandlers will not be called
when the startElementHandler is not set.

I'll post more details in a follow-up.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-10-08 13:40

Message:
Logged In: YES 
user_id=290026

I am not *that* eager <g>.
You take care of it.

Thanks!

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-10-08 13:36

Message:
Logged In: YES 
user_id=3066

Original patch checked in as lib/xmlparse.c 1.92 and
tests/runtests.c 1.36, before I saw Karl's comments.

Karl:  Yes, we should probably fix things so the namespace
decl handlers can be set independently, as the API suggests.
 I can take care of this, unless you beat me to it.  ;-)

Don't know that it warrants a separate issue report, so I'll
leave this one as fixed but open for now.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-10-08 13:21

Message:
Logged In: YES 
user_id=290026

Yes, verified. To be precise, addBinding() can call back
to startNamespaceDeclHandler() which then allows
the application to clear the startElementHandler.

One comment: storeAtts() is called like this

  if (startElementHandler) {
    result = storeAtts(parser, ...);
    ...
  }

presumably because the attributes should only be
stored if needed for the startElementHandler.
However, storeAtts does double duty by also
processing namespace declarations and calling
startNamespaceDeclHandler().

So, if that handler is set, should then not storeAtts()
be called like this:

  if (startElementHandler || startNamespaceDeclHandler)
  {
    result = storeAtts(parser, ...);
    ...
  }

And, if true, one should then apply this logic to the
other occasions when storeAtts() is called.

Or does it not make sense to set 
startNamespaceDeclHandler when
startElementHandler is cleared?



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

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

From noreply at sourceforge.net  Tue Jan 21 19:31:06 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 21 22:27:20 2003
Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault: bad API/callback
	interaction
Message-ID: <E18bBbW-0007A3-00@sc8-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: segfault: bad API/callback interaction

Initial Comment:
There is a bad interaction between the call to the
start element handler and the Expat API:  After the
presence of the callback is checked, the addBinding()
function can call XML_SetStartElementHandler(parser,
NULL), after which doContent() will still attempt to
call the start element handler.  This results in a call
to the NULL address, resulting in a memory fault.

This is unlikely to be an issue for applications
written entirely in C, but can reasonably happen when a
wrapper library clears callbacks when an error
condition or exception has been detected.

I've attached a patch and a regression test for this case.


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-21 22:31

Message:
Logged In: YES 
user_id=3066

While I really like the idea that each handler is completely
independent, as the API suggests, I'm not aware of any
real-world use case that requires the namespace callbacks
but not the element boundary callbacks.  Without the use
cases, I think we can live with documented limitations.  As
long as limitations are documented, higher-level layers can
implement the fully-decoupled callbacks model if needed, by
registering "dummy" callbacks as needed to take the place of
application-level callbacks.

Since I've added notes to the documentation about the
limitations relevant to this issue report, I think this is
safe to close if there are no objections in the next day or so.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 14:32

Message:
Logged In: YES 
user_id=290026

The patch passes the OASIS test-suite correctly, but
I am not sure it is worth the extra CPU cycles to make
the namespace declaration handlers truly independent
of the startElementHandler.

Any use cases for that?

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 11:59

Message:
Logged In: YES 
user_id=290026

I have attached a patch (ElmHandlers.diff) that calls
storeAtts whenever any of the attribute related handlers
is called, i.e. :
- startElmHandler, 
- startNamespaceDeclHandler, and
- endNamespaceDeclHandler.

The default handler calls are adjusted appropriately.

This patch should make it possible to have the 
namespace declaration handlers called even when 
no startElementHandlers is set.

Please review. Not tested yet.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-21 11:14

Message:
Logged In: YES 
user_id=3066

Added notes about the limitation in the documentation:
doc/reference.html 1.41

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 10:55

Message:
Logged In: YES 
user_id=290026

I had another look and this looks trickier than I thought.
I suggest we add documentation that states that
the start/endNamespaceDeclHandlers will not be called
when the startElementHandler is not set.

I'll post more details in a follow-up.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-10-08 13:40

Message:
Logged In: YES 
user_id=290026

I am not *that* eager <g>.
You take care of it.

Thanks!

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-10-08 13:36

Message:
Logged In: YES 
user_id=3066

Original patch checked in as lib/xmlparse.c 1.92 and
tests/runtests.c 1.36, before I saw Karl's comments.

Karl:  Yes, we should probably fix things so the namespace
decl handlers can be set independently, as the API suggests.
 I can take care of this, unless you beat me to it.  ;-)

Don't know that it warrants a separate issue report, so I'll
leave this one as fixed but open for now.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-10-08 13:21

Message:
Logged In: YES 
user_id=290026

Yes, verified. To be precise, addBinding() can call back
to startNamespaceDeclHandler() which then allows
the application to clear the startElementHandler.

One comment: storeAtts() is called like this

  if (startElementHandler) {
    result = storeAtts(parser, ...);
    ...
  }

presumably because the attributes should only be
stored if needed for the startElementHandler.
However, storeAtts does double duty by also
processing namespace declarations and calling
startNamespaceDeclHandler().

So, if that handler is set, should then not storeAtts()
be called like this:

  if (startElementHandler || startNamespaceDeclHandler)
  {
    result = storeAtts(parser, ...);
    ...
  }

And, if true, one should then apply this logic to the
other occasions when storeAtts() is called.

Or does it not make sense to set 
startNamespaceDeclHandler when
startElementHandler is cleared?



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

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

From fdrake at acm.org  Tue Jan 21 22:51:05 2003
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Tue Jan 21 22:51:30 2003
Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault: bad
	API/callbackinteraction
In-Reply-To: <003a01c2c167$ef5eb9b0$9e539696@citkwaclaww2k>
References: <E18b0kO-0005zs-00@sc8-sf-web2.sourceforge.net>
	<003a01c2c167$ef5eb9b0$9e539696@citkwaclaww2k>
Message-ID: <15918.5417.236599.796112@grendel.zope.com>


Karl Waclawek writes:
 > Here is the follow-up I promised:

I've followed up in the tracker:

https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620343&group_id=10127


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation

From karl at waclawek.net  Wed Jan 22 00:02:52 2003
From: karl at waclawek.net (Karl Waclawek)
Date: Wed Jan 22 00:02:47 2003
Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault:
	badAPI/callbackinteraction
References: 
	<E18b0kO-0005zs-00@sc8-sf-web2.sourceforge.net><003a01c2c167$ef5eb9b0$9e539696@citkwaclaww2k>
	<15918.5417.236599.796112@grendel.zope.com>
Message-ID: <001201c2c1d3$8488e720$0207a8c0@karl>


> Karl Waclawek writes:
>  > Here is the follow-up I promised:
> 
> I've followed up in the tracker:
> 
> https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620343&group_id=10127
> 

There are three smaller problems that remain:

1) defaultHandler call - related to your patch
   Current code:

        if (startElementHandler) {
          result = storeAtts(parser, enc, s, &(tag->name), &(tag->bindings));
          if (result)
            return result;
          if (startElementHandler)
            startElementHandler(handlerArg, tag->name.str,
                                (const XML_Char **)atts);
        }
        else if (defaultHandler)
          reportDefault(parser, enc, s, next);

this should be changed to:

        if (startElementHandler) {
          result = storeAtts(parser, enc, s, &(tag->name), &(tag->bindings));
          if (result)
            return result;
          if (startElementHandler)
            startElementHandler(handlerArg, tag->name.str,
                                (const XML_Char **)atts);
          else if (defaultHandler)
            reportDefault(parser, enc, s, next);
        }
        else if (defaultHandler)
          reportDefault(parser, enc, s, next);

since - as you noticed - the startElementHandler could be turned off
in the startNamespaceDeclHandler callback.

2) Same as 1) for the empty element tag, but not as simple
   to solve. Consider these 4 cases:
   a) no element handler set
   b) startElementHandler set
   c) endElementHandler set
   d) both element handlers set
Now, when should the default handler be called?
The answers is difficult for case c), since the endElementHandler
does not report attributes. So, if we don't call the default handler
for c), attributes go completely unreported, but if we do, we will
double report the element name.

What is your opinion? I tend to think that the default handler
is the substitue for the startElementHandler rather than the
endElementHandler, so I would say, call the default handler for c).

One could of course be fancy and check if there are any attributes.
If yes, call it, if no, don't. But nothing really satisfies.

The solution would be simple if start- and endElementHandler could
only be set or cleared together, but not independently.

3) It is possible that storeAtts gets called twice:

    case XML_TOK_EMPTY_ELEMENT_WITH_ATTS:
      if (!startElementHandler) {
        enum XML_Error result = storeAtts(parser, enc, s, 0, 0);
        if (result)
          return result;
      }
      /* fall through */
    case XML_TOK_EMPTY_ELEMENT_NO_ATTS:
      if (startElementHandler || endElementHandler) {
        ...
        result = storeAtts(parser, enc, s, &name, &bindings);
        if (result)
          return result;

I suggest this fix:

    case XML_TOK_EMPTY_ELEMENT_WITH_ATTS:
      if (!startElementHandler && !endElementHandler) {
        enum XML_Error result = storeAtts(parser, enc, s, 0, 0);
        if (result)
          return result;
      }
      /* fall through */
    case XML_TOK_EMPTY_ELEMENT_NO_ATTS:
      if (startElementHandler || endElementHandler) {
        ...
        result = storeAtts(parser, enc, s, &name, &bindings);
        if (result)
          return result;


Karl

From fdrake at acm.org  Wed Jan 22 02:05:44 2003
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Wed Jan 22 02:06:08 2003
Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault:
	badAPI/callbackinteraction
In-Reply-To: <001201c2c1d3$8488e720$0207a8c0@karl>
References: <E18b0kO-0005zs-00@sc8-sf-web2.sourceforge.net>
	<003a01c2c167$ef5eb9b0$9e539696@citkwaclaww2k>
	<15918.5417.236599.796112@grendel.zope.com>
	<001201c2c1d3$8488e720$0207a8c0@karl>
Message-ID: <15918.17096.124705.929279@grendel.zope.com>


Karl Waclawek writes:
 > 1) defaultHandler call - related to your patch
 >    Current code:
 > 
 >         if (startElementHandler) {
 >           result = storeAtts(parser, enc, s, &(tag->name), &(tag->bindings));
 >           if (result)
 >             return result;
 >           if (startElementHandler)
 >             startElementHandler(handlerArg, tag->name.str,
 >                                 (const XML_Char **)atts);
 >         }
 >         else if (defaultHandler)
 >           reportDefault(parser, enc, s, next);
 > 
 > this should be changed to:
 > 
 >         if (startElementHandler) {
 >           result = storeAtts(parser, enc, s, &(tag->name), &(tag->bindings));
 >           if (result)
 >             return result;
 >           if (startElementHandler)
 >             startElementHandler(handlerArg, tag->name.str,
 >                                 (const XML_Char **)atts);
 >           else if (defaultHandler)
 >             reportDefault(parser, enc, s, next);
 >         }
 >         else if (defaultHandler)
 >           reportDefault(parser, enc, s, next);
 > 
 > since - as you noticed - the startElementHandler could be turned off
 > in the startNamespaceDeclHandler callback.

Agreed.  Please commit the change when you get a chance.

 > 2) Same as 1) for the empty element tag, but not as simple
 >    to solve. Consider these 4 cases:
 >    a) no element handler set
 >    b) startElementHandler set
 >    c) endElementHandler set
 >    d) both element handlers set
 > Now, when should the default handler be called?
 > The answers is difficult for case c), since the endElementHandler
 > does not report attributes. So, if we don't call the default handler
 > for c), attributes go completely unreported, but if we do, we will
 > double report the element name.
 > 
 > What is your opinion? I tend to think that the default handler
 > is the substitue for the startElementHandler rather than the
 > endElementHandler, so I would say, call the default handler for c).

The way I think of the default handler is that it is called for markup
that is not otherwise reported; the only tricky one is when there is
only an end element handler and default handler.  I'd err on the side
of not calling the default handler; the end element handler does
report the markup, but not necessarily in a comprehensive way.

Others who rely more on the default handler should chime in on this
topic.  ;-)

 > One could of course be fancy and check if there are any attributes.
 > If yes, call it, if no, don't. But nothing really satisfies.

No!  Too painful to explain and accomodate in the application.

 > The solution would be simple if start- and endElementHandler could
 > only be set or cleared together, but not independently.

By which I presume you mean that we also require both to be NULL or
both non-NULL.  That would be a real potential nuissance for current
users; even if an application uses both or none, it may use the
SetStart... and SetEnd... instead of Set(both) functions to make the
changes; this is certainly how the Python bindings work.  It's
possible to write the binding to call the Set(both) function, but more
painful to "pair up" settings of the handlers when changing them from
set to not-set without substantial API changes at the Python level
(dummy handlers would have to be introduced, and more state checked
and managed while changing the handlers).  I don't know if any of the
other bindings would suffer that limitation.

 > 3) It is possible that storeAtts gets called twice:
...
 > I suggest this fix:

This looks good; please check it in at your leisure!  ;-)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation

From karl at waclawek.net  Wed Jan 22 09:32:19 2003
From: karl at waclawek.net (Karl Waclawek)
Date: Wed Jan 22 09:32:26 2003
Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault:
	badAPI/callbackinteraction
References: 
	<E18b0kO-0005zs-00@sc8-sf-web2.sourceforge.net><003a01c2c167$ef5eb9b0$9e539696@citkwaclaww2k><15918.5417.236599.796112@grendel.zope.com><001201c2c1d3$8488e720$0207a8c0@karl>
	<15918.17096.124705.929279@grendel.zope.com>
Message-ID: <001301c2c223$1179e400$9e539696@citkwaclaww2k>

>  > 2) Same as 1) for the empty element tag, but not as simple
>  >    to solve. Consider these 4 cases:
>  >    a) no element handler set
>  >    b) startElementHandler set
>  >    c) endElementHandler set
>  >    d) both element handlers set
>  > Now, when should the default handler be called?
>  > The answers is difficult for case c), since the endElementHandler
>  > does not report attributes. So, if we don't call the default handler
>  > for c), attributes go completely unreported, but if we do, we will
>  > double report the element name.
>  > 
>  > What is your opinion? I tend to think that the default handler
>  > is the substitue for the startElementHandler rather than the
>  > endElementHandler, so I would say, call the default handler for c).
> 
> The way I think of the default handler is that it is called for markup
> that is not otherwise reported; the only tricky one is when there is
> only an end element handler and default handler.  I'd err on the side
> of not calling the default handler; the end element handler does
> report the markup, but not necessarily in a comprehensive way.
> 
> Others who rely more on the default handler should chime in on this
> topic.  ;-)

I vaguely remember Rolf Ade being one of them. Am I right, Rolf?
Any input?

> 
>  > One could of course be fancy and check if there are any attributes.
>  > If yes, call it, if no, don't. But nothing really satisfies.
> 
> No!  Too painful to explain and accomodate in the application.

I agree.

>  > The solution would be simple if start- and endElementHandler could
>  > only be set or cleared together, but not independently.
> 
> By which I presume you mean that we also require both to be NULL or
> both non-NULL.  That would be a real potential nuissance for current
> users; even if an application uses both or none, it may use the
> SetStart... and SetEnd... instead of Set(both) functions to make the
> changes; 

Yes, it implies an API change!

> this is certainly how the Python bindings work.  It's
> possible to write the binding to call the Set(both) function, but more
> painful to "pair up" settings of the handlers when changing them from
> set to not-set without substantial API changes at the Python level
> (dummy handlers would have to be introduced, and more state checked
> and managed while changing the handlers).  I don't know if any of the
> other bindings would suffer that limitation.

Since I need to apply a fix like the one for case 1) anyway, I'll go
with your suggestion for c): default handler not called,
when endElementHandler is set, but not startElementHandler.

If there is a good reason for a different behaviour, anyone
please jump in. To recap, we will have:

   a) no element handler set:    call default handler
   b) startElementHandler set:   do not call default handler
   c) endElementHandler set:     do not call default handler
   d) both element handlers set: do not call default handler

>  > 3) It is possible that storeAtts gets called twice:
> ...
>  > I suggest this fix:
> 
> This looks good; please check it in at your leisure!  ;-)

Done.

Karl

From noreply at sourceforge.net  Thu Jan 23 12:39:38 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jan 23 15:36:55 2003
Subject: [Expat-bugs] [ expat-Bugs-609603 ] v1.95.5 Win32 static lib symbol
	problem
Message-ID: <E18bo8Q-0005xk-00@sc8-sf-web3.sourceforge.net>

Bugs item #609603, was opened at 2002-09-15 12:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=609603&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: v1.95.5 Win32 static lib symbol problem

Initial Comment:
I just switched over to using the Win32 static lib 
version of Expat in my MSVC++ application.

Now, it appears that the following line:

#define _STATIC

is required before

#include "expat.h"

otherwise, the link fails.



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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-23 15:39

Message:
Logged In: YES 
user_id=3066

Static linking on Unix is a non-starter -- every platform
handles all linking differently, and developers hate their
lives if they have to go beyond writing code to actually
linking an application together.  There's nothing
Expat-specific in this sea of misery.

I don't know what a Windows programmer needs to be told, so
someone will have to tell me, or provide a patch.  It sounds
like there's a problem there, but I've no idea offhand if
that's unique to the static Expat libraries, or endemic to
Windows.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-09-15 12:50

Message:
Logged In: YES 
user_id=290026

Either that, or you define _STATIC in the Project Settings.
Have a look at the "elements" demo project, it is
statically linked.

However, I think it is not enough to just have the demo
project, we should document this as well.

I'll assign this to Fred, since the documentation
needs to include static linking instructions for
Unix systems too.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-09-15 12:29

Message:
Logged In: NO 




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

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

From noreply at sourceforge.net  Thu Jan 23 12:53:51 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jan 23 15:49:59 2003
Subject: [Expat-bugs] [ expat-Bugs-609603 ] v1.95.5 Win32 static lib symbol
	problem
Message-ID: <E18boMB-0003hm-00@sc8-sf-web1.sourceforge.net>

Bugs item #609603, was opened at 2002-09-15 12:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=609603&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: v1.95.5 Win32 static lib symbol problem

Initial Comment:
I just switched over to using the Win32 static lib 
version of Expat in my MSVC++ application.

Now, it appears that the following line:

#define _STATIC

is required before

#include "expat.h"

otherwise, the link fails.



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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 15:53

Message:
Logged In: YES 
user_id=290026

The static linking for Windows is documented in
the ReadMe file under the Win32 directory.

But is that enough, or should some documentation
be added elsewhere - at least the fact that the
global macro XML_STATIC needs to be defined?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-23 15:39

Message:
Logged In: YES 
user_id=3066

Static linking on Unix is a non-starter -- every platform
handles all linking differently, and developers hate their
lives if they have to go beyond writing code to actually
linking an application together.  There's nothing
Expat-specific in this sea of misery.

I don't know what a Windows programmer needs to be told, so
someone will have to tell me, or provide a patch.  It sounds
like there's a problem there, but I've no idea offhand if
that's unique to the static Expat libraries, or endemic to
Windows.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-09-15 12:50

Message:
Logged In: YES 
user_id=290026

Either that, or you define _STATIC in the Project Settings.
Have a look at the "elements" demo project, it is
statically linked.

However, I think it is not enough to just have the demo
project, we should document this as well.

I'll assign this to Fred, since the documentation
needs to include static linking instructions for
Unix systems too.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-09-15 12:29

Message:
Logged In: NO 




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

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

From noreply at sourceforge.net  Thu Jan 23 13:00:39 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jan 23 15:56:48 2003
Subject: [Expat-bugs] [ expat-Bugs-632146 ] xmlwf: memory demands
Message-ID: <E18boSl-0007sS-00@sc8-sf-web4.sourceforge.net>

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

>Category: Documentation
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Rolf Ade (pointsman)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xmlwf: memory demands

Initial Comment:

expat 1.95.5

Running xmlwf against bigger XML files needs almost the
double of the file  size of memory (at the end, the
process size grows permanently during the  processing).
This looks pretty wrong to me, since the tool does SAX
parsing.

Please notice, that this seems to be a problem only
with the xmlwf code, not with the expat lib per se. An
application by me, build on top of expat, doesn't shows
this behavior. Instead, the memory size of the process
stays constant and pretty low, even while parsing big
XML files - which is, what I also would have expected
from the xmlwf tool.

I'm sorry, for only reporting the problem and not
digging into.

rolf


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-23 16:00

Message:
Logged In: YES 
user_id=3066

This needs documentation, at least.  I don't see any
problems with the mmap code in xmlwf/unixfilemap.c.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-11-20 19:10

Message:
Logged In: YES 
user_id=290026

As it turns out - after reading the manual - the default
behaviour of xmlwf is to use memory mapped files.
This explains the observed use of memory.

With the -r option xmlwf can be made to use
regular file I/O, and then memory use is as expected.

Maybe the question could be asked if xmlwf
should have a different default behaviour.
But then it would not be backwards compatible.

Leave open for Fred to comment.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-11-20 13:52

Message:
Logged In: YES 
user_id=290026

The files you used for testing:

- Do they have an internal and/or external DTD subset?
- Are there external or internal entity references?
- Are there attributes on some/all elements?

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

Comment By: Rolf Ade (pointsman)
Date: 2002-11-20 13:25

Message:
Logged In: YES 
user_id=13222

The problem shows even with no options given to xmlwf. i.e.
xmlwf  <xmlFile>

Just use a (big)  XML file and watch the xmlwf process grow
in the process table. (You need a really big one (several 10
MBytes) to have a change to see it with ordinary ps (on
unix) or the task manager (on MS), because otherwise expat
is finished, before you had a chance to see anything ;.)).

No, I would bet, it's not a (classical)  memory leak. I've
memory debugged expat based applications several times, and
the lib doesn't leak memory (or only very seldom under rare
circumstances,)

I've just valgrind'ed (mem leak checker) an xmlwf run, which
shows the depicted behavior (xmlwf process size grows far to
much), but there is no mem leak -. no pointer to allocated
memory is lost, and all allocated memory is cleand up at the
end. So eventually there are depending on the file size used
some really big buffers, or something else.

rolf


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-11-20 11:36

Message:
Logged In: YES 
user_id=290026

I fixed a small memory leak, but don't think this
applies here - the leak would only occur under certain
error conditions.

I couldn't really find a problem in the xmlwf code
at a first check. Does this memory leak also happen 
with older versions of  the expat lib?

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

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

Message:
Logged In: YES 
user_id=290026

What options are you using when calling xmlwf?

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

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

From noreply at sourceforge.net  Thu Jan 23 13:30:18 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jan 23 16:26:33 2003
Subject: [Expat-bugs] [ expat-Bugs-632146 ] xmlwf: memory demands
Message-ID: <E18bovS-0005yu-00@sc8-sf-web1.sourceforge.net>

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

Category: Documentation
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Rolf Ade (pointsman)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xmlwf: memory demands

Initial Comment:

expat 1.95.5

Running xmlwf against bigger XML files needs almost the
double of the file  size of memory (at the end, the
process size grows permanently during the  processing).
This looks pretty wrong to me, since the tool does SAX
parsing.

Please notice, that this seems to be a problem only
with the xmlwf code, not with the expat lib per se. An
application by me, build on top of expat, doesn't shows
this behavior. Instead, the memory size of the process
stays constant and pretty low, even while parsing big
XML files - which is, what I also would have expected
from the xmlwf tool.

I'm sorry, for only reporting the problem and not
digging into.

rolf


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 16:30

Message:
Logged In: YES 
user_id=290026

I don't think there *are* problems, I guess the observed
behaviour simply is a consequence of memory mapping.
It just behaves unexpectedly, and so we should 
document it.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-23 16:00

Message:
Logged In: YES 
user_id=3066

This needs documentation, at least.  I don't see any
problems with the mmap code in xmlwf/unixfilemap.c.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-11-20 19:10

Message:
Logged In: YES 
user_id=290026

As it turns out - after reading the manual - the default
behaviour of xmlwf is to use memory mapped files.
This explains the observed use of memory.

With the -r option xmlwf can be made to use
regular file I/O, and then memory use is as expected.

Maybe the question could be asked if xmlwf
should have a different default behaviour.
But then it would not be backwards compatible.

Leave open for Fred to comment.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-11-20 13:52

Message:
Logged In: YES 
user_id=290026

The files you used for testing:

- Do they have an internal and/or external DTD subset?
- Are there external or internal entity references?
- Are there attributes on some/all elements?

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

Comment By: Rolf Ade (pointsman)
Date: 2002-11-20 13:25

Message:
Logged In: YES 
user_id=13222

The problem shows even with no options given to xmlwf. i.e.
xmlwf  <xmlFile>

Just use a (big)  XML file and watch the xmlwf process grow
in the process table. (You need a really big one (several 10
MBytes) to have a change to see it with ordinary ps (on
unix) or the task manager (on MS), because otherwise expat
is finished, before you had a chance to see anything ;.)).

No, I would bet, it's not a (classical)  memory leak. I've
memory debugged expat based applications several times, and
the lib doesn't leak memory (or only very seldom under rare
circumstances,)

I've just valgrind'ed (mem leak checker) an xmlwf run, which
shows the depicted behavior (xmlwf process size grows far to
much), but there is no mem leak -. no pointer to allocated
memory is lost, and all allocated memory is cleand up at the
end. So eventually there are depending on the file size used
some really big buffers, or something else.

rolf


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-11-20 11:36

Message:
Logged In: YES 
user_id=290026

I fixed a small memory leak, but don't think this
applies here - the leak would only occur under certain
error conditions.

I couldn't really find a problem in the xmlwf code
at a first check. Does this memory leak also happen 
with older versions of  the expat lib?

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

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

Message:
Logged In: YES 
user_id=290026

What options are you using when calling xmlwf?

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

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

From noreply at sourceforge.net  Thu Jan 23 19:47:00 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jan 23 22:42:53 2003
Subject: [Expat-bugs] [ expat-Patches-673791 ] Error with xmlns:prefix="" 
Message-ID: <E18buo0-0004ss-00@sc8-sf-web3.sourceforge.net>

Patches item #673791, was opened at 2003-01-23 20:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=673791&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error with xmlns:prefix="" 

Initial Comment:
When processing a document in namespace mode, the 
following document should be in error (according to XML 
Namespaces 1.0 Section 2): 
 
<?xml version='1.0'?> 
<docelem xmlns:pre=""/> 
 
However, it is being processed just fine. 
 
With the attached patch, this error is properly reported (only 
when namespace processing is enabled). 
 
I hope this can get in before the 1.95.6 release. 
 
Thanks, 
Jeremy Kloth 

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

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

From noreply at sourceforge.net  Thu Jan 23 19:49:51 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jan 23 22:45:46 2003
Subject: [Expat-bugs] [ expat-Patches-673791 ] Error with xmlns:prefix="" 
Message-ID: <E18buql-0004xh-00@sc8-sf-web3.sourceforge.net>

Patches item #673791, was opened at 2003-01-23 20:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=673791&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Error with xmlns:prefix="" 

Initial Comment:
When processing a document in namespace mode, the 
following document should be in error (according to XML 
Namespaces 1.0 Section 2): 
 
<?xml version='1.0'?> 
<docelem xmlns:pre=""/> 
 
However, it is being processed just fine. 
 
With the attached patch, this error is properly reported (only 
when namespace processing is enabled). 
 
I hope this can get in before the 1.95.6 release. 
 
Thanks, 
Jeremy Kloth 

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

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

From noreply at sourceforge.net  Thu Jan 23 20:37:34 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jan 23 23:33:46 2003
Subject: [Expat-bugs] [ expat-Patches-673791 ] Error with xmlns:prefix="" 
Message-ID: <E18bvaw-0005oq-00@sc8-sf-web2.sourceforge.net>

Patches item #673791, was opened at 2003-01-23 22:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=673791&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Error with xmlns:prefix="" 

Initial Comment:
When processing a document in namespace mode, the 
following document should be in error (according to XML 
Namespaces 1.0 Section 2): 
 
<?xml version='1.0'?> 
<docelem xmlns:pre=""/> 
 
However, it is being processed just fine. 
 
With the attached patch, this error is properly reported (only 
when namespace processing is enabled). 
 
I hope this can get in before the 1.95.6 release. 
 
Thanks, 
Jeremy Kloth 

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 23:37

Message:
Logged In: YES 
user_id=290026

Yes, it seems the NS specs do not allow a prefix name with 
an empty URI. This patch looks OK to me - if Fred agrees, I 
can commit it. 

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

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

From noreply at sourceforge.net  Thu Jan 23 21:03:33 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jan 23 23:59:27 2003
Subject: [Expat-bugs] [ expat-Patches-673791 ] Error with xmlns:prefix="" 
Message-ID: <E18bw05-0006n6-00@sc8-sf-web3.sourceforge.net>

Patches item #673791, was opened at 2003-01-23 22:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=673791&group_id=10127

Category: None
Group: None
Status: Open
>Resolution: Accepted
>Priority: 6
Submitted By: Jeremy Kloth (jkloth)
>Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Error with xmlns:prefix="" 

Initial Comment:
When processing a document in namespace mode, the 
following document should be in error (according to XML 
Namespaces 1.0 Section 2): 
 
<?xml version='1.0'?> 
<docelem xmlns:pre=""/> 
 
However, it is being processed just fine. 
 
With the attached patch, this error is properly reported (only 
when namespace processing is enabled). 
 
I hope this can get in before the 1.95.6 release. 
 
Thanks, 
Jeremy Kloth 

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:03

Message:
Logged In: YES 
user_id=3066

I think you're right.  I haven't looked at the patch yet,
but the spec is (almost) clear about this.

I will note that I consider this more a bug in the namespace
spec than a desirable feature or constraint to test:  It
makes more sense (to me) to allow the use of xmlns:prefix=''
to "un-declare" the prefix (possibly making it an error of
some sort to un-declare a prefix that doesn't have an active
declaration).  But that's my opinion, not the letter of the
spec.

I'll mark this as accepted (for concept), and work up a test
case before committing anything.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 23:37

Message:
Logged In: YES 
user_id=290026

Yes, it seems the NS specs do not allow a prefix name with 
an empty URI. This patch looks OK to me - if Fred agrees, I 
can commit it. 

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

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

From noreply at sourceforge.net  Thu Jan 23 21:08:19 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan 24 00:04:23 2003
Subject: [Expat-bugs] [ expat-Patches-673791 ] Error with xmlns:prefix="" 
Message-ID: <E18bw4h-0008A5-00@sc8-sf-web4.sourceforge.net>

Patches item #673791, was opened at 2003-01-23 22:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=673791&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 6
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Error with xmlns:prefix="" 

Initial Comment:
When processing a document in namespace mode, the 
following document should be in error (according to XML 
Namespaces 1.0 Section 2): 
 
<?xml version='1.0'?> 
<docelem xmlns:pre=""/> 
 
However, it is being processed just fine. 
 
With the attached patch, this error is properly reported (only 
when namespace processing is enabled). 
 
I hope this can get in before the 1.95.6 release. 
 
Thanks, 
Jeremy Kloth 

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 00:08

Message:
Logged In: YES 
user_id=290026

Sorry, Fred.

I jumped the gun - wanted to finish it before going to bed.
It really looks OK, so I don't feel I risked too much.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:03

Message:
Logged In: YES 
user_id=3066

I think you're right.  I haven't looked at the patch yet,
but the spec is (almost) clear about this.

I will note that I consider this more a bug in the namespace
spec than a desirable feature or constraint to test:  It
makes more sense (to me) to allow the use of xmlns:prefix=''
to "un-declare" the prefix (possibly making it an error of
some sort to un-declare a prefix that doesn't have an active
declaration).  But that's my opinion, not the letter of the
spec.

I'll mark this as accepted (for concept), and work up a test
case before committing anything.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 23:37

Message:
Logged In: YES 
user_id=290026

Yes, it seems the NS specs do not allow a prefix name with 
an empty URI. This patch looks OK to me - if Fred agrees, I 
can commit it. 

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

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

From noreply at sourceforge.net  Thu Jan 23 21:20:32 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan 24 00:16:33 2003
Subject: [Expat-bugs] [ expat-Patches-673791 ] Error with xmlns:prefix="" 
Message-ID: <E18bwGW-0005Gc-00@sc8-sf-web1.sourceforge.net>

Patches item #673791, was opened at 2003-01-23 22:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=673791&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 6
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Error with xmlns:prefix="" 

Initial Comment:
When processing a document in namespace mode, the 
following document should be in error (according to XML 
Namespaces 1.0 Section 2): 
 
<?xml version='1.0'?> 
<docelem xmlns:pre=""/> 
 
However, it is being processed just fine. 
 
With the attached patch, this error is properly reported (only 
when namespace processing is enabled). 
 
I hope this can get in before the 1.95.6 release. 
 
Thanks, 
Jeremy Kloth 

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:20

Message:
Logged In: YES 
user_id=3066

What Karl didn't say was that he checked in the patch as
lib/xmlparse.c revision 1.105.  ;-)  I'll just avoid doing a
"cvs up" until the test is done -- should be soon.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 00:08

Message:
Logged In: YES 
user_id=290026

Sorry, Fred.

I jumped the gun - wanted to finish it before going to bed.
It really looks OK, so I don't feel I risked too much.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:03

Message:
Logged In: YES 
user_id=3066

I think you're right.  I haven't looked at the patch yet,
but the spec is (almost) clear about this.

I will note that I consider this more a bug in the namespace
spec than a desirable feature or constraint to test:  It
makes more sense (to me) to allow the use of xmlns:prefix=''
to "un-declare" the prefix (possibly making it an error of
some sort to un-declare a prefix that doesn't have an active
declaration).  But that's my opinion, not the letter of the
spec.

I'll mark this as accepted (for concept), and work up a test
case before committing anything.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 23:37

Message:
Logged In: YES 
user_id=290026

Yes, it seems the NS specs do not allow a prefix name with 
an empty URI. This patch looks OK to me - if Fred agrees, I 
can commit it. 

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

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

From noreply at sourceforge.net  Thu Jan 23 21:41:56 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan 24 00:38:08 2003
Subject: [Expat-bugs] [ expat-Patches-673791 ] Error with xmlns:prefix="" 
Message-ID: <E18bwbE-0007Uv-00@sc8-sf-web2.sourceforge.net>

Patches item #673791, was opened at 2003-01-23 20:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=673791&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 6
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Error with xmlns:prefix="" 

Initial Comment:
When processing a document in namespace mode, the 
following document should be in error (according to XML 
Namespaces 1.0 Section 2): 
 
<?xml version='1.0'?> 
<docelem xmlns:pre=""/> 
 
However, it is being processed just fine. 
 
With the attached patch, this error is properly reported (only 
when namespace processing is enabled). 
 
I hope this can get in before the 1.95.6 release. 
 
Thanks, 
Jeremy Kloth 

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

>Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-23 22:41

Message:
Logged In: YES 
user_id=38980

As far as the bug in the namespace spec goes, they addressed just 
his particular issue with XML NS 1.1.  However that would required XML 
1.1 processing which I'm not sure is something that is needed right 
now (although it is in canidate rec). 

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-23 22:20

Message:
Logged In: YES 
user_id=3066

What Karl didn't say was that he checked in the patch as
lib/xmlparse.c revision 1.105.  ;-)  I'll just avoid doing a
"cvs up" until the test is done -- should be soon.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 22:08

Message:
Logged In: YES 
user_id=290026

Sorry, Fred.

I jumped the gun - wanted to finish it before going to bed.
It really looks OK, so I don't feel I risked too much.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-23 22:03

Message:
Logged In: YES 
user_id=3066

I think you're right.  I haven't looked at the patch yet,
but the spec is (almost) clear about this.

I will note that I consider this more a bug in the namespace
spec than a desirable feature or constraint to test:  It
makes more sense (to me) to allow the use of xmlns:prefix=''
to "un-declare" the prefix (possibly making it an error of
some sort to un-declare a prefix that doesn't have an active
declaration).  But that's my opinion, not the letter of the
spec.

I'll mark this as accepted (for concept), and work up a test
case before committing anything.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 21:37

Message:
Logged In: YES 
user_id=290026

Yes, it seems the NS specs do not allow a prefix name with 
an empty URI. This patch looks OK to me - if Fred agrees, I 
can commit it. 

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

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

From noreply at sourceforge.net  Thu Jan 23 21:58:14 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan 24 00:54:06 2003
Subject: [Expat-bugs] [ expat-Patches-673791 ] Error with xmlns:prefix="" 
Message-ID: <E18bwr0-0007wT-00@sc8-sf-web3.sourceforge.net>

Patches item #673791, was opened at 2003-01-23 22:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=673791&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Accepted
>Priority: 7
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Error with xmlns:prefix="" 

Initial Comment:
When processing a document in namespace mode, the 
following document should be in error (according to XML 
Namespaces 1.0 Section 2): 
 
<?xml version='1.0'?> 
<docelem xmlns:pre=""/> 
 
However, it is being processed just fine. 
 
With the attached patch, this error is properly reported (only 
when namespace processing is enabled). 
 
I hope this can get in before the 1.95.6 release. 
 
Thanks, 
Jeremy Kloth 

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:58

Message:
Logged In: YES 
user_id=3066

Ok, *now* I'm not happy.  I've done my "cvs up", and the
patch doesn't appear to have fixed the problem.  Perhaps I
don't have proper tests yet?  I've attached them to this
issue report.  I expected these tests to pass with current
CVS since Karl checked in Jeremy's patch.

I'll have to deal with this tomorrow; I'm too tired to go
trawling through this just yet.  The patched looked fine on
the surface; did it work for you?

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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-24 00:41

Message:
Logged In: YES 
user_id=38980

As far as the bug in the namespace spec goes, they addressed just 
his particular issue with XML NS 1.1.  However that would required XML 
1.1 processing which I'm not sure is something that is needed right 
now (although it is in canidate rec). 

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:20

Message:
Logged In: YES 
user_id=3066

What Karl didn't say was that he checked in the patch as
lib/xmlparse.c revision 1.105.  ;-)  I'll just avoid doing a
"cvs up" until the test is done -- should be soon.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 00:08

Message:
Logged In: YES 
user_id=290026

Sorry, Fred.

I jumped the gun - wanted to finish it before going to bed.
It really looks OK, so I don't feel I risked too much.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:03

Message:
Logged In: YES 
user_id=3066

I think you're right.  I haven't looked at the patch yet,
but the spec is (almost) clear about this.

I will note that I consider this more a bug in the namespace
spec than a desirable feature or constraint to test:  It
makes more sense (to me) to allow the use of xmlns:prefix=''
to "un-declare" the prefix (possibly making it an error of
some sort to un-declare a prefix that doesn't have an active
declaration).  But that's my opinion, not the letter of the
spec.

I'll mark this as accepted (for concept), and work up a test
case before committing anything.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 23:37

Message:
Logged In: YES 
user_id=290026

Yes, it seems the NS specs do not allow a prefix name with 
an empty URI. This patch looks OK to me - if Fred agrees, I 
can commit it. 

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

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

From noreply at sourceforge.net  Thu Jan 23 22:00:44 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan 24 00:56:36 2003
Subject: [Expat-bugs] [ expat-Patches-673791 ] Error with xmlns:prefix="" 
Message-ID: <E18bwtQ-0007zH-00@sc8-sf-web3.sourceforge.net>

Patches item #673791, was opened at 2003-01-23 22:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=673791&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 7
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Error with xmlns:prefix="" 

Initial Comment:
When processing a document in namespace mode, the 
following document should be in error (according to XML 
Namespaces 1.0 Section 2): 
 
<?xml version='1.0'?> 
<docelem xmlns:pre=""/> 
 
However, it is being processed just fine. 
 
With the attached patch, this error is properly reported (only 
when namespace processing is enabled). 
 
I hope this can get in before the 1.95.6 release. 
 
Thanks, 
Jeremy Kloth 

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 01:00

Message:
Logged In: YES 
user_id=3066

Jeremy:  Thanks for the update with regard to XML NS 1.1.  I
agree we don't need to worry about that yet; it's more
important to fix bugs with regard to XML 1.0 and the first
version of the namespaces spec.  See my previous note.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:58

Message:
Logged In: YES 
user_id=3066

Ok, *now* I'm not happy.  I've done my "cvs up", and the
patch doesn't appear to have fixed the problem.  Perhaps I
don't have proper tests yet?  I've attached them to this
issue report.  I expected these tests to pass with current
CVS since Karl checked in Jeremy's patch.

I'll have to deal with this tomorrow; I'm too tired to go
trawling through this just yet.  The patched looked fine on
the surface; did it work for you?

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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-24 00:41

Message:
Logged In: YES 
user_id=38980

As far as the bug in the namespace spec goes, they addressed just 
his particular issue with XML NS 1.1.  However that would required XML 
1.1 processing which I'm not sure is something that is needed right 
now (although it is in canidate rec). 

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:20

Message:
Logged In: YES 
user_id=3066

What Karl didn't say was that he checked in the patch as
lib/xmlparse.c revision 1.105.  ;-)  I'll just avoid doing a
"cvs up" until the test is done -- should be soon.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 00:08

Message:
Logged In: YES 
user_id=290026

Sorry, Fred.

I jumped the gun - wanted to finish it before going to bed.
It really looks OK, so I don't feel I risked too much.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:03

Message:
Logged In: YES 
user_id=3066

I think you're right.  I haven't looked at the patch yet,
but the spec is (almost) clear about this.

I will note that I consider this more a bug in the namespace
spec than a desirable feature or constraint to test:  It
makes more sense (to me) to allow the use of xmlns:prefix=''
to "un-declare" the prefix (possibly making it an error of
some sort to un-declare a prefix that doesn't have an active
declaration).  But that's my opinion, not the letter of the
spec.

I'll mark this as accepted (for concept), and work up a test
case before committing anything.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 23:37

Message:
Logged In: YES 
user_id=290026

Yes, it seems the NS specs do not allow a prefix name with 
an empty URI. This patch looks OK to me - if Fred agrees, I 
can commit it. 

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

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

From noreply at sourceforge.net  Fri Jan 24 07:29:25 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan 24 10:25:45 2003
Subject: [Expat-bugs] [ expat-Bugs-632146 ] xmlwf: memory demands
Message-ID: <E18c5ll-0004OT-00@sc8-sf-web1.sourceforge.net>

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

Category: Documentation
Group: Not a Bug
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Rolf Ade (pointsman)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xmlwf: memory demands

Initial Comment:

expat 1.95.5

Running xmlwf against bigger XML files needs almost the
double of the file  size of memory (at the end, the
process size grows permanently during the  processing).
This looks pretty wrong to me, since the tool does SAX
parsing.

Please notice, that this seems to be a problem only
with the xmlwf code, not with the expat lib per se. An
application by me, build on top of expat, doesn't shows
this behavior. Instead, the memory size of the process
stays constant and pretty low, even while parsing big
XML files - which is, what I also would have expected
from the xmlwf tool.

I'm sorry, for only reporting the problem and not
digging into.

rolf


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 10:29

Message:
Logged In: YES 
user_id=3066

Documentation updated in doc/xmlwf.sgml 1.3.  Closing this
report.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 16:30

Message:
Logged In: YES 
user_id=290026

I don't think there *are* problems, I guess the observed
behaviour simply is a consequence of memory mapping.
It just behaves unexpectedly, and so we should 
document it.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-23 16:00

Message:
Logged In: YES 
user_id=3066

This needs documentation, at least.  I don't see any
problems with the mmap code in xmlwf/unixfilemap.c.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-11-20 19:10

Message:
Logged In: YES 
user_id=290026

As it turns out - after reading the manual - the default
behaviour of xmlwf is to use memory mapped files.
This explains the observed use of memory.

With the -r option xmlwf can be made to use
regular file I/O, and then memory use is as expected.

Maybe the question could be asked if xmlwf
should have a different default behaviour.
But then it would not be backwards compatible.

Leave open for Fred to comment.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-11-20 13:52

Message:
Logged In: YES 
user_id=290026

The files you used for testing:

- Do they have an internal and/or external DTD subset?
- Are there external or internal entity references?
- Are there attributes on some/all elements?

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

Comment By: Rolf Ade (pointsman)
Date: 2002-11-20 13:25

Message:
Logged In: YES 
user_id=13222

The problem shows even with no options given to xmlwf. i.e.
xmlwf  <xmlFile>

Just use a (big)  XML file and watch the xmlwf process grow
in the process table. (You need a really big one (several 10
MBytes) to have a change to see it with ordinary ps (on
unix) or the task manager (on MS), because otherwise expat
is finished, before you had a chance to see anything ;.)).

No, I would bet, it's not a (classical)  memory leak. I've
memory debugged expat based applications several times, and
the lib doesn't leak memory (or only very seldom under rare
circumstances,)

I've just valgrind'ed (mem leak checker) an xmlwf run, which
shows the depicted behavior (xmlwf process size grows far to
much), but there is no mem leak -. no pointer to allocated
memory is lost, and all allocated memory is cleand up at the
end. So eventually there are depending on the file size used
some really big buffers, or something else.

rolf


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-11-20 11:36

Message:
Logged In: YES 
user_id=290026

I fixed a small memory leak, but don't think this
applies here - the leak would only occur under certain
error conditions.

I couldn't really find a problem in the xmlwf code
at a first check. Does this memory leak also happen 
with older versions of  the expat lib?

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

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

Message:
Logged In: YES 
user_id=290026

What options are you using when calling xmlwf?

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

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

From noreply at sourceforge.net  Fri Jan 24 20:45:36 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan 24 23:41:31 2003
Subject: [Expat-bugs] [ expat-Patches-673791 ] Error with xmlns:prefix="" 
Message-ID: <E18cICG-0002Ig-00@sc8-sf-web1.sourceforge.net>

Patches item #673791, was opened at 2003-01-23 22:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=673791&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 7
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Error with xmlns:prefix="" 

Initial Comment:
When processing a document in namespace mode, the 
following document should be in error (according to XML 
Namespaces 1.0 Section 2): 
 
<?xml version='1.0'?> 
<docelem xmlns:pre=""/> 
 
However, it is being processed just fine. 
 
With the attached patch, this error is properly reported (only 
when namespace processing is enabled). 
 
I hope this can get in before the 1.95.6 release. 
 
Thanks, 
Jeremy Kloth 

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 23:45

Message:
Logged In: YES 
user_id=290026

This patch does not work when no startElementHandler
is set, since then namespace declaration will not be 
processed - a recently documented limitation in Expat.

I have attached a new patch (on top of Jeremy's) which
should fix this, so that namespace declaration will
be processed and checked all the time.

Two files are attached:
- elmHandlers.txt: a brief overview/explanation
- elmHandlers.diff: the patch (against xmlparse.c rev. 1.105)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 01:00

Message:
Logged In: YES 
user_id=3066

Jeremy:  Thanks for the update with regard to XML NS 1.1.  I
agree we don't need to worry about that yet; it's more
important to fix bugs with regard to XML 1.0 and the first
version of the namespaces spec.  See my previous note.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:58

Message:
Logged In: YES 
user_id=3066

Ok, *now* I'm not happy.  I've done my "cvs up", and the
patch doesn't appear to have fixed the problem.  Perhaps I
don't have proper tests yet?  I've attached them to this
issue report.  I expected these tests to pass with current
CVS since Karl checked in Jeremy's patch.

I'll have to deal with this tomorrow; I'm too tired to go
trawling through this just yet.  The patched looked fine on
the surface; did it work for you?

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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-24 00:41

Message:
Logged In: YES 
user_id=38980

As far as the bug in the namespace spec goes, they addressed just 
his particular issue with XML NS 1.1.  However that would required XML 
1.1 processing which I'm not sure is something that is needed right 
now (although it is in canidate rec). 

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:20

Message:
Logged In: YES 
user_id=3066

What Karl didn't say was that he checked in the patch as
lib/xmlparse.c revision 1.105.  ;-)  I'll just avoid doing a
"cvs up" until the test is done -- should be soon.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 00:08

Message:
Logged In: YES 
user_id=290026

Sorry, Fred.

I jumped the gun - wanted to finish it before going to bed.
It really looks OK, so I don't feel I risked too much.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:03

Message:
Logged In: YES 
user_id=3066

I think you're right.  I haven't looked at the patch yet,
but the spec is (almost) clear about this.

I will note that I consider this more a bug in the namespace
spec than a desirable feature or constraint to test:  It
makes more sense (to me) to allow the use of xmlns:prefix=''
to "un-declare" the prefix (possibly making it an error of
some sort to un-declare a prefix that doesn't have an active
declaration).  But that's my opinion, not the letter of the
spec.

I'll mark this as accepted (for concept), and work up a test
case before committing anything.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 23:37

Message:
Logged In: YES 
user_id=290026

Yes, it seems the NS specs do not allow a prefix name with 
an empty URI. This patch looks OK to me - if Fred agrees, I 
can commit it. 

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

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

From noreply at sourceforge.net  Fri Jan 24 20:46:39 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan 24 23:42:34 2003
Subject: [Expat-bugs] [ expat-Patches-673791 ] Error with xmlns:prefix="" 
Message-ID: <E18cIDH-0002Jd-00@sc8-sf-web1.sourceforge.net>

Patches item #673791, was opened at 2003-01-23 22:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=673791&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 7
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Error with xmlns:prefix="" 

Initial Comment:
When processing a document in namespace mode, the 
following document should be in error (according to XML 
Namespaces 1.0 Section 2): 
 
<?xml version='1.0'?> 
<docelem xmlns:pre=""/> 
 
However, it is being processed just fine. 
 
With the attached patch, this error is properly reported (only 
when namespace processing is enabled). 
 
I hope this can get in before the 1.95.6 release. 
 
Thanks, 
Jeremy Kloth 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 23:45

Message:
Logged In: YES 
user_id=290026

This patch does not work when no startElementHandler
is set, since then namespace declaration will not be 
processed - a recently documented limitation in Expat.

I have attached a new patch (on top of Jeremy's) which
should fix this, so that namespace declaration will
be processed and checked all the time.

Two files are attached:
- elmHandlers.txt: a brief overview/explanation
- elmHandlers.diff: the patch (against xmlparse.c rev. 1.105)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 01:00

Message:
Logged In: YES 
user_id=3066

Jeremy:  Thanks for the update with regard to XML NS 1.1.  I
agree we don't need to worry about that yet; it's more
important to fix bugs with regard to XML 1.0 and the first
version of the namespaces spec.  See my previous note.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:58

Message:
Logged In: YES 
user_id=3066

Ok, *now* I'm not happy.  I've done my "cvs up", and the
patch doesn't appear to have fixed the problem.  Perhaps I
don't have proper tests yet?  I've attached them to this
issue report.  I expected these tests to pass with current
CVS since Karl checked in Jeremy's patch.

I'll have to deal with this tomorrow; I'm too tired to go
trawling through this just yet.  The patched looked fine on
the surface; did it work for you?

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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-24 00:41

Message:
Logged In: YES 
user_id=38980

As far as the bug in the namespace spec goes, they addressed just 
his particular issue with XML NS 1.1.  However that would required XML 
1.1 processing which I'm not sure is something that is needed right 
now (although it is in canidate rec). 

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:20

Message:
Logged In: YES 
user_id=3066

What Karl didn't say was that he checked in the patch as
lib/xmlparse.c revision 1.105.  ;-)  I'll just avoid doing a
"cvs up" until the test is done -- should be soon.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 00:08

Message:
Logged In: YES 
user_id=290026

Sorry, Fred.

I jumped the gun - wanted to finish it before going to bed.
It really looks OK, so I don't feel I risked too much.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:03

Message:
Logged In: YES 
user_id=3066

I think you're right.  I haven't looked at the patch yet,
but the spec is (almost) clear about this.

I will note that I consider this more a bug in the namespace
spec than a desirable feature or constraint to test:  It
makes more sense (to me) to allow the use of xmlns:prefix=''
to "un-declare" the prefix (possibly making it an error of
some sort to un-declare a prefix that doesn't have an active
declaration).  But that's my opinion, not the letter of the
spec.

I'll mark this as accepted (for concept), and work up a test
case before committing anything.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 23:37

Message:
Logged In: YES 
user_id=290026

Yes, it seems the NS specs do not allow a prefix name with 
an empty URI. This patch looks OK to me - if Fred agrees, I 
can commit it. 

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

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

From noreply at sourceforge.net  Fri Jan 24 20:49:23 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan 24 23:45:17 2003
Subject: [Expat-bugs] [ expat-Patches-673791 ] Error with xmlns:prefix="" 
Message-ID: <E18cIFv-0002Mc-00@sc8-sf-web1.sourceforge.net>

Patches item #673791, was opened at 2003-01-23 22:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=673791&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 7
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Error with xmlns:prefix="" 

Initial Comment:
When processing a document in namespace mode, the 
following document should be in error (according to XML 
Namespaces 1.0 Section 2): 
 
<?xml version='1.0'?> 
<docelem xmlns:pre=""/> 
 
However, it is being processed just fine. 
 
With the attached patch, this error is properly reported (only 
when namespace processing is enabled). 
 
I hope this can get in before the 1.95.6 release. 
 
Thanks, 
Jeremy Kloth 

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 23:49

Message:
Logged In: YES 
user_id=290026

I tested this against the OASIS test-suite and a few large
files with no problems. Hope it passes our suite of regression 
tests as well.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 23:45

Message:
Logged In: YES 
user_id=290026

This patch does not work when no startElementHandler
is set, since then namespace declaration will not be 
processed - a recently documented limitation in Expat.

I have attached a new patch (on top of Jeremy's) which
should fix this, so that namespace declaration will
be processed and checked all the time.

Two files are attached:
- elmHandlers.txt: a brief overview/explanation
- elmHandlers.diff: the patch (against xmlparse.c rev. 1.105)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 01:00

Message:
Logged In: YES 
user_id=3066

Jeremy:  Thanks for the update with regard to XML NS 1.1.  I
agree we don't need to worry about that yet; it's more
important to fix bugs with regard to XML 1.0 and the first
version of the namespaces spec.  See my previous note.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:58

Message:
Logged In: YES 
user_id=3066

Ok, *now* I'm not happy.  I've done my "cvs up", and the
patch doesn't appear to have fixed the problem.  Perhaps I
don't have proper tests yet?  I've attached them to this
issue report.  I expected these tests to pass with current
CVS since Karl checked in Jeremy's patch.

I'll have to deal with this tomorrow; I'm too tired to go
trawling through this just yet.  The patched looked fine on
the surface; did it work for you?

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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-24 00:41

Message:
Logged In: YES 
user_id=38980

As far as the bug in the namespace spec goes, they addressed just 
his particular issue with XML NS 1.1.  However that would required XML 
1.1 processing which I'm not sure is something that is needed right 
now (although it is in canidate rec). 

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:20

Message:
Logged In: YES 
user_id=3066

What Karl didn't say was that he checked in the patch as
lib/xmlparse.c revision 1.105.  ;-)  I'll just avoid doing a
"cvs up" until the test is done -- should be soon.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 00:08

Message:
Logged In: YES 
user_id=290026

Sorry, Fred.

I jumped the gun - wanted to finish it before going to bed.
It really looks OK, so I don't feel I risked too much.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:03

Message:
Logged In: YES 
user_id=3066

I think you're right.  I haven't looked at the patch yet,
but the spec is (almost) clear about this.

I will note that I consider this more a bug in the namespace
spec than a desirable feature or constraint to test:  It
makes more sense (to me) to allow the use of xmlns:prefix=''
to "un-declare" the prefix (possibly making it an error of
some sort to un-declare a prefix that doesn't have an active
declaration).  But that's my opinion, not the letter of the
spec.

I'll mark this as accepted (for concept), and work up a test
case before committing anything.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 23:37

Message:
Logged In: YES 
user_id=290026

Yes, it seems the NS specs do not allow a prefix name with 
an empty URI. This patch looks OK to me - if Fred agrees, I 
can commit it. 

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

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

From noreply at sourceforge.net  Fri Jan 24 22:17:11 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jan 25 01:17:43 2003
Subject: [Expat-bugs] [ expat-Patches-673791 ] Error with xmlns:prefix="" 
Message-ID: <E18cJct-0001nv-00@sc8-sf-web4.sourceforge.net>

Patches item #673791, was opened at 2003-01-23 22:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=673791&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 7
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Error with xmlns:prefix="" 

Initial Comment:
When processing a document in namespace mode, the 
following document should be in error (according to XML 
Namespaces 1.0 Section 2): 
 
<?xml version='1.0'?> 
<docelem xmlns:pre=""/> 
 
However, it is being processed just fine. 
 
With the attached patch, this error is properly reported (only 
when namespace processing is enabled). 
 
I hope this can get in before the 1.95.6 release. 
 
Thanks, 
Jeremy Kloth 

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

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

Message:
Logged In: YES 
user_id=290026

Found already a bug in the fix:

In the case of a start element event, it does not store the
name, which is a problem if there is an endElementHandler.

Revised fix attached as elHandlers2.diif with the description
in elmHandlers2.txt.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 23:49

Message:
Logged In: YES 
user_id=290026

I tested this against the OASIS test-suite and a few large
files with no problems. Hope it passes our suite of regression 
tests as well.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 23:45

Message:
Logged In: YES 
user_id=290026

This patch does not work when no startElementHandler
is set, since then namespace declaration will not be 
processed - a recently documented limitation in Expat.

I have attached a new patch (on top of Jeremy's) which
should fix this, so that namespace declaration will
be processed and checked all the time.

Two files are attached:
- elmHandlers.txt: a brief overview/explanation
- elmHandlers.diff: the patch (against xmlparse.c rev. 1.105)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 01:00

Message:
Logged In: YES 
user_id=3066

Jeremy:  Thanks for the update with regard to XML NS 1.1.  I
agree we don't need to worry about that yet; it's more
important to fix bugs with regard to XML 1.0 and the first
version of the namespaces spec.  See my previous note.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:58

Message:
Logged In: YES 
user_id=3066

Ok, *now* I'm not happy.  I've done my "cvs up", and the
patch doesn't appear to have fixed the problem.  Perhaps I
don't have proper tests yet?  I've attached them to this
issue report.  I expected these tests to pass with current
CVS since Karl checked in Jeremy's patch.

I'll have to deal with this tomorrow; I'm too tired to go
trawling through this just yet.  The patched looked fine on
the surface; did it work for you?

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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-24 00:41

Message:
Logged In: YES 
user_id=38980

As far as the bug in the namespace spec goes, they addressed just 
his particular issue with XML NS 1.1.  However that would required XML 
1.1 processing which I'm not sure is something that is needed right 
now (although it is in canidate rec). 

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:20

Message:
Logged In: YES 
user_id=3066

What Karl didn't say was that he checked in the patch as
lib/xmlparse.c revision 1.105.  ;-)  I'll just avoid doing a
"cvs up" until the test is done -- should be soon.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 00:08

Message:
Logged In: YES 
user_id=290026

Sorry, Fred.

I jumped the gun - wanted to finish it before going to bed.
It really looks OK, so I don't feel I risked too much.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:03

Message:
Logged In: YES 
user_id=3066

I think you're right.  I haven't looked at the patch yet,
but the spec is (almost) clear about this.

I will note that I consider this more a bug in the namespace
spec than a desirable feature or constraint to test:  It
makes more sense (to me) to allow the use of xmlns:prefix=''
to "un-declare" the prefix (possibly making it an error of
some sort to un-declare a prefix that doesn't have an active
declaration).  But that's my opinion, not the letter of the
spec.

I'll mark this as accepted (for concept), and work up a test
case before committing anything.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 23:37

Message:
Logged In: YES 
user_id=290026

Yes, it seems the NS specs do not allow a prefix name with 
an empty URI. This patch looks OK to me - if Fred agrees, I 
can commit it. 

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

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

From noreply at sourceforge.net  Fri Jan 24 23:01:50 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jan 25 02:35:56 2003
Subject: [Expat-bugs] [ expat-Patches-673791 ] Error with xmlns:prefix="" 
Message-ID: <E18cKK6-0002p7-00@sc8-sf-web4.sourceforge.net>

Patches item #673791, was opened at 2003-01-23 22:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=673791&group_id=10127

Category: None
Group: None
Status: Open
>Resolution: Fixed
>Priority: 6
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Error with xmlns:prefix="" 

Initial Comment:
When processing a document in namespace mode, the 
following document should be in error (according to XML 
Namespaces 1.0 Section 2): 
 
<?xml version='1.0'?> 
<docelem xmlns:pre=""/> 
 
However, it is being processed just fine. 
 
With the attached patch, this error is properly reported (only 
when namespace processing is enabled). 
 
I hope this can get in before the 1.95.6 release. 
 
Thanks, 
Jeremy Kloth 

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-25 02:01

Message:
Logged In: YES 
user_id=3066

Committed Karl's latest patch as lib/xmlparse.c 1.106, with
most of his explanation in the commit message.  Portions
need to be incorporated as source comments as well.

Regression tests committed as tests/runtests.c 1.47.

Marked bug as fixed; still need to incorporate additional
source comments, so it remains open, with priority reduced
slightly.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-25 01:17

Message:
Logged In: YES 
user_id=290026

Found already a bug in the fix:

In the case of a start element event, it does not store the
name, which is a problem if there is an endElementHandler.

Revised fix attached as elHandlers2.diif with the description
in elmHandlers2.txt.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 23:49

Message:
Logged In: YES 
user_id=290026

I tested this against the OASIS test-suite and a few large
files with no problems. Hope it passes our suite of regression 
tests as well.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 23:45

Message:
Logged In: YES 
user_id=290026

This patch does not work when no startElementHandler
is set, since then namespace declaration will not be 
processed - a recently documented limitation in Expat.

I have attached a new patch (on top of Jeremy's) which
should fix this, so that namespace declaration will
be processed and checked all the time.

Two files are attached:
- elmHandlers.txt: a brief overview/explanation
- elmHandlers.diff: the patch (against xmlparse.c rev. 1.105)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 01:00

Message:
Logged In: YES 
user_id=3066

Jeremy:  Thanks for the update with regard to XML NS 1.1.  I
agree we don't need to worry about that yet; it's more
important to fix bugs with regard to XML 1.0 and the first
version of the namespaces spec.  See my previous note.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:58

Message:
Logged In: YES 
user_id=3066

Ok, *now* I'm not happy.  I've done my "cvs up", and the
patch doesn't appear to have fixed the problem.  Perhaps I
don't have proper tests yet?  I've attached them to this
issue report.  I expected these tests to pass with current
CVS since Karl checked in Jeremy's patch.

I'll have to deal with this tomorrow; I'm too tired to go
trawling through this just yet.  The patched looked fine on
the surface; did it work for you?

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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-24 00:41

Message:
Logged In: YES 
user_id=38980

As far as the bug in the namespace spec goes, they addressed just 
his particular issue with XML NS 1.1.  However that would required XML 
1.1 processing which I'm not sure is something that is needed right 
now (although it is in canidate rec). 

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:20

Message:
Logged In: YES 
user_id=3066

What Karl didn't say was that he checked in the patch as
lib/xmlparse.c revision 1.105.  ;-)  I'll just avoid doing a
"cvs up" until the test is done -- should be soon.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 00:08

Message:
Logged In: YES 
user_id=290026

Sorry, Fred.

I jumped the gun - wanted to finish it before going to bed.
It really looks OK, so I don't feel I risked too much.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:03

Message:
Logged In: YES 
user_id=3066

I think you're right.  I haven't looked at the patch yet,
but the spec is (almost) clear about this.

I will note that I consider this more a bug in the namespace
spec than a desirable feature or constraint to test:  It
makes more sense (to me) to allow the use of xmlns:prefix=''
to "un-declare" the prefix (possibly making it an error of
some sort to un-declare a prefix that doesn't have an active
declaration).  But that's my opinion, not the letter of the
spec.

I'll mark this as accepted (for concept), and work up a test
case before committing anything.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 23:37

Message:
Logged In: YES 
user_id=290026

Yes, it seems the NS specs do not allow a prefix name with 
an empty URI. This patch looks OK to me - if Fred agrees, I 
can commit it. 

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

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

From noreply at sourceforge.net  Fri Jan 24 22:17:44 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jan 25 03:50:24 2003
Subject: [Expat-bugs] [ expat-Patches-673791 ] Error with xmlns:prefix="" 
Message-ID: <E18cJdQ-0001ok-00@sc8-sf-web4.sourceforge.net>

Patches item #673791, was opened at 2003-01-23 22:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=673791&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 7
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Error with xmlns:prefix="" 

Initial Comment:
When processing a document in namespace mode, the 
following document should be in error (according to XML 
Namespaces 1.0 Section 2): 
 
<?xml version='1.0'?> 
<docelem xmlns:pre=""/> 
 
However, it is being processed just fine. 
 
With the attached patch, this error is properly reported (only 
when namespace processing is enabled). 
 
I hope this can get in before the 1.95.6 release. 
 
Thanks, 
Jeremy Kloth 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-25 01:17

Message:
Logged In: YES 
user_id=290026

Found already a bug in the fix:

In the case of a start element event, it does not store the
name, which is a problem if there is an endElementHandler.

Revised fix attached as elHandlers2.diif with the description
in elmHandlers2.txt.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 23:49

Message:
Logged In: YES 
user_id=290026

I tested this against the OASIS test-suite and a few large
files with no problems. Hope it passes our suite of regression 
tests as well.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 23:45

Message:
Logged In: YES 
user_id=290026

This patch does not work when no startElementHandler
is set, since then namespace declaration will not be 
processed - a recently documented limitation in Expat.

I have attached a new patch (on top of Jeremy's) which
should fix this, so that namespace declaration will
be processed and checked all the time.

Two files are attached:
- elmHandlers.txt: a brief overview/explanation
- elmHandlers.diff: the patch (against xmlparse.c rev. 1.105)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 01:00

Message:
Logged In: YES 
user_id=3066

Jeremy:  Thanks for the update with regard to XML NS 1.1.  I
agree we don't need to worry about that yet; it's more
important to fix bugs with regard to XML 1.0 and the first
version of the namespaces spec.  See my previous note.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:58

Message:
Logged In: YES 
user_id=3066

Ok, *now* I'm not happy.  I've done my "cvs up", and the
patch doesn't appear to have fixed the problem.  Perhaps I
don't have proper tests yet?  I've attached them to this
issue report.  I expected these tests to pass with current
CVS since Karl checked in Jeremy's patch.

I'll have to deal with this tomorrow; I'm too tired to go
trawling through this just yet.  The patched looked fine on
the surface; did it work for you?

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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-24 00:41

Message:
Logged In: YES 
user_id=38980

As far as the bug in the namespace spec goes, they addressed just 
his particular issue with XML NS 1.1.  However that would required XML 
1.1 processing which I'm not sure is something that is needed right 
now (although it is in canidate rec). 

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:20

Message:
Logged In: YES 
user_id=3066

What Karl didn't say was that he checked in the patch as
lib/xmlparse.c revision 1.105.  ;-)  I'll just avoid doing a
"cvs up" until the test is done -- should be soon.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 00:08

Message:
Logged In: YES 
user_id=290026

Sorry, Fred.

I jumped the gun - wanted to finish it before going to bed.
It really looks OK, so I don't feel I risked too much.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:03

Message:
Logged In: YES 
user_id=3066

I think you're right.  I haven't looked at the patch yet,
but the spec is (almost) clear about this.

I will note that I consider this more a bug in the namespace
spec than a desirable feature or constraint to test:  It
makes more sense (to me) to allow the use of xmlns:prefix=''
to "un-declare" the prefix (possibly making it an error of
some sort to un-declare a prefix that doesn't have an active
declaration).  But that's my opinion, not the letter of the
spec.

I'll mark this as accepted (for concept), and work up a test
case before committing anything.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 23:37

Message:
Logged In: YES 
user_id=290026

Yes, it seems the NS specs do not allow a prefix name with 
an empty URI. This patch looks OK to me - if Fred agrees, I 
can commit it. 

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

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

From noreply at sourceforge.net  Sun Jan 26 20:14:04 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jan 26 23:09:52 2003
Subject: [Expat-bugs] [ expat-Patches-673791 ] Error with xmlns:prefix="" 
Message-ID: <E18d0eq-00051G-00@sc8-sf-web2.sourceforge.net>

Patches item #673791, was opened at 2003-01-23 22:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=673791&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Fixed
Priority: 6
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Error with xmlns:prefix="" 

Initial Comment:
When processing a document in namespace mode, the 
following document should be in error (according to XML 
Namespaces 1.0 Section 2): 
 
<?xml version='1.0'?> 
<docelem xmlns:pre=""/> 
 
However, it is being processed just fine. 
 
With the attached patch, this error is properly reported (only 
when namespace processing is enabled). 
 
I hope this can get in before the 1.95.6 release. 
 
Thanks, 
Jeremy Kloth 

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-26 23:14

Message:
Logged In: YES 
user_id=290026

I found two additional flaws that show up when no 
startElementHandler is set for an element without attributes
(since storeAtts will not be called then):

1) Attributes will not be defaulted, and NS declarations based
on defaulted attributes will not be processed or checked, even
with Jeremy's fix. E.g. this document will pass without error:

<!DOCTYPE doc [
    <!ELEMENT doc (#PCDATA)>
    <!ATTLIST doc
        xmlns:pre CDATA "">
]>
<doc>some data</doc>

2) The element name will be stored but not prepared for 
proper namespace reporting (see ns_triplets), which is
a problem if there is an endElementHandler.

Similar arguments apply for empty elements that have no 
attributes.

So the solution is to always call storeAtts.
This may have a performance impact for the case
when no element handlers are set.

See attached files elmHandlers4.diff/txt.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-25 02:01

Message:
Logged In: YES 
user_id=3066

Committed Karl's latest patch as lib/xmlparse.c 1.106, with
most of his explanation in the commit message.  Portions
need to be incorporated as source comments as well.

Regression tests committed as tests/runtests.c 1.47.

Marked bug as fixed; still need to incorporate additional
source comments, so it remains open, with priority reduced
slightly.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-25 01:17

Message:
Logged In: YES 
user_id=290026

Found already a bug in the fix:

In the case of a start element event, it does not store the
name, which is a problem if there is an endElementHandler.

Revised fix attached as elHandlers2.diif with the description
in elmHandlers2.txt.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 23:49

Message:
Logged In: YES 
user_id=290026

I tested this against the OASIS test-suite and a few large
files with no problems. Hope it passes our suite of regression 
tests as well.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 23:45

Message:
Logged In: YES 
user_id=290026

This patch does not work when no startElementHandler
is set, since then namespace declaration will not be 
processed - a recently documented limitation in Expat.

I have attached a new patch (on top of Jeremy's) which
should fix this, so that namespace declaration will
be processed and checked all the time.

Two files are attached:
- elmHandlers.txt: a brief overview/explanation
- elmHandlers.diff: the patch (against xmlparse.c rev. 1.105)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 01:00

Message:
Logged In: YES 
user_id=3066

Jeremy:  Thanks for the update with regard to XML NS 1.1.  I
agree we don't need to worry about that yet; it's more
important to fix bugs with regard to XML 1.0 and the first
version of the namespaces spec.  See my previous note.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:58

Message:
Logged In: YES 
user_id=3066

Ok, *now* I'm not happy.  I've done my "cvs up", and the
patch doesn't appear to have fixed the problem.  Perhaps I
don't have proper tests yet?  I've attached them to this
issue report.  I expected these tests to pass with current
CVS since Karl checked in Jeremy's patch.

I'll have to deal with this tomorrow; I'm too tired to go
trawling through this just yet.  The patched looked fine on
the surface; did it work for you?

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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-24 00:41

Message:
Logged In: YES 
user_id=38980

As far as the bug in the namespace spec goes, they addressed just 
his particular issue with XML NS 1.1.  However that would required XML 
1.1 processing which I'm not sure is something that is needed right 
now (although it is in canidate rec). 

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:20

Message:
Logged In: YES 
user_id=3066

What Karl didn't say was that he checked in the patch as
lib/xmlparse.c revision 1.105.  ;-)  I'll just avoid doing a
"cvs up" until the test is done -- should be soon.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 00:08

Message:
Logged In: YES 
user_id=290026

Sorry, Fred.

I jumped the gun - wanted to finish it before going to bed.
It really looks OK, so I don't feel I risked too much.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:03

Message:
Logged In: YES 
user_id=3066

I think you're right.  I haven't looked at the patch yet,
but the spec is (almost) clear about this.

I will note that I consider this more a bug in the namespace
spec than a desirable feature or constraint to test:  It
makes more sense (to me) to allow the use of xmlns:prefix=''
to "un-declare" the prefix (possibly making it an error of
some sort to un-declare a prefix that doesn't have an active
declaration).  But that's my opinion, not the letter of the
spec.

I'll mark this as accepted (for concept), and work up a test
case before committing anything.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 23:37

Message:
Logged In: YES 
user_id=290026

Yes, it seems the NS specs do not allow a prefix name with 
an empty URI. This patch looks OK to me - if Fred agrees, I 
can commit it. 

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

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

From noreply at sourceforge.net  Sun Jan 26 20:20:23 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jan 26 23:15:58 2003
Subject: [Expat-bugs] [ expat-Patches-673791 ] Error with xmlns:prefix="" 
Message-ID: <E18d0kx-0004sT-00@sc8-sf-web1.sourceforge.net>

Patches item #673791, was opened at 2003-01-23 22:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=673791&group_id=10127

Category: None
Group: None
Status: Open
Resolution: Fixed
Priority: 6
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Error with xmlns:prefix="" 

Initial Comment:
When processing a document in namespace mode, the 
following document should be in error (according to XML 
Namespaces 1.0 Section 2): 
 
<?xml version='1.0'?> 
<docelem xmlns:pre=""/> 
 
However, it is being processed just fine. 
 
With the attached patch, this error is properly reported (only 
when namespace processing is enabled). 
 
I hope this can get in before the 1.95.6 release. 
 
Thanks, 
Jeremy Kloth 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-26 23:14

Message:
Logged In: YES 
user_id=290026

I found two additional flaws that show up when no 
startElementHandler is set for an element without attributes
(since storeAtts will not be called then):

1) Attributes will not be defaulted, and NS declarations based
on defaulted attributes will not be processed or checked, even
with Jeremy's fix. E.g. this document will pass without error:

<!DOCTYPE doc [
    <!ELEMENT doc (#PCDATA)>
    <!ATTLIST doc
        xmlns:pre CDATA "">
]>
<doc>some data</doc>

2) The element name will be stored but not prepared for 
proper namespace reporting (see ns_triplets), which is
a problem if there is an endElementHandler.

Similar arguments apply for empty elements that have no 
attributes.

So the solution is to always call storeAtts.
This may have a performance impact for the case
when no element handlers are set.

See attached files elmHandlers4.diff/txt.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-25 02:01

Message:
Logged In: YES 
user_id=3066

Committed Karl's latest patch as lib/xmlparse.c 1.106, with
most of his explanation in the commit message.  Portions
need to be incorporated as source comments as well.

Regression tests committed as tests/runtests.c 1.47.

Marked bug as fixed; still need to incorporate additional
source comments, so it remains open, with priority reduced
slightly.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-25 01:17

Message:
Logged In: YES 
user_id=290026

Found already a bug in the fix:

In the case of a start element event, it does not store the
name, which is a problem if there is an endElementHandler.

Revised fix attached as elHandlers2.diif with the description
in elmHandlers2.txt.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 23:49

Message:
Logged In: YES 
user_id=290026

I tested this against the OASIS test-suite and a few large
files with no problems. Hope it passes our suite of regression 
tests as well.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 23:45

Message:
Logged In: YES 
user_id=290026

This patch does not work when no startElementHandler
is set, since then namespace declaration will not be 
processed - a recently documented limitation in Expat.

I have attached a new patch (on top of Jeremy's) which
should fix this, so that namespace declaration will
be processed and checked all the time.

Two files are attached:
- elmHandlers.txt: a brief overview/explanation
- elmHandlers.diff: the patch (against xmlparse.c rev. 1.105)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 01:00

Message:
Logged In: YES 
user_id=3066

Jeremy:  Thanks for the update with regard to XML NS 1.1.  I
agree we don't need to worry about that yet; it's more
important to fix bugs with regard to XML 1.0 and the first
version of the namespaces spec.  See my previous note.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:58

Message:
Logged In: YES 
user_id=3066

Ok, *now* I'm not happy.  I've done my "cvs up", and the
patch doesn't appear to have fixed the problem.  Perhaps I
don't have proper tests yet?  I've attached them to this
issue report.  I expected these tests to pass with current
CVS since Karl checked in Jeremy's patch.

I'll have to deal with this tomorrow; I'm too tired to go
trawling through this just yet.  The patched looked fine on
the surface; did it work for you?

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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-24 00:41

Message:
Logged In: YES 
user_id=38980

As far as the bug in the namespace spec goes, they addressed just 
his particular issue with XML NS 1.1.  However that would required XML 
1.1 processing which I'm not sure is something that is needed right 
now (although it is in canidate rec). 

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:20

Message:
Logged In: YES 
user_id=3066

What Karl didn't say was that he checked in the patch as
lib/xmlparse.c revision 1.105.  ;-)  I'll just avoid doing a
"cvs up" until the test is done -- should be soon.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 00:08

Message:
Logged In: YES 
user_id=290026

Sorry, Fred.

I jumped the gun - wanted to finish it before going to bed.
It really looks OK, so I don't feel I risked too much.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:03

Message:
Logged In: YES 
user_id=3066

I think you're right.  I haven't looked at the patch yet,
but the spec is (almost) clear about this.

I will note that I consider this more a bug in the namespace
spec than a desirable feature or constraint to test:  It
makes more sense (to me) to allow the use of xmlns:prefix=''
to "un-declare" the prefix (possibly making it an error of
some sort to un-declare a prefix that doesn't have an active
declaration).  But that's my opinion, not the letter of the
spec.

I'll mark this as accepted (for concept), and work up a test
case before committing anything.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 23:37

Message:
Logged In: YES 
user_id=290026

Yes, it seems the NS specs do not allow a prefix name with 
an empty URI. This patch looks OK to me - if Fred agrees, I 
can commit it. 

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

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

From noreply at sourceforge.net  Mon Jan 27 21:53:35 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 28 00:49:02 2003
Subject: [Expat-bugs] [ expat-Patches-673791 ] Error with xmlns:prefix="" 
Message-ID: <E18dOgh-0005hm-00@sc8-sf-web4.sourceforge.net>

Patches item #673791, was opened at 2003-01-23 22:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=673791&group_id=10127

Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Error with xmlns:prefix="" 

Initial Comment:
When processing a document in namespace mode, the 
following document should be in error (according to XML 
Namespaces 1.0 Section 2): 
 
<?xml version='1.0'?> 
<docelem xmlns:pre=""/> 
 
However, it is being processed just fine. 
 
With the attached patch, this error is properly reported (only 
when namespace processing is enabled). 
 
I hope this can get in before the 1.95.6 release. 
 
Thanks, 
Jeremy Kloth 

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 00:53

Message:
Logged In: YES 
user_id=3066

Right again!  I've committed your fix as lib/xmlparse.c 1.107, 
and added tests that check the relevant conditions.

Regarding the performance question, I don't think this is a 
problem.  Most "real" applications will require both start and 
end element handlers anyway, in which case we improve 
performance by avoiding some checks in storeAtts(), and for 
simple well-formedness testing (where the handlers are not 
needed), we gain correctness -- an acceptable trade.

Thanks, Karl!

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-26 23:14

Message:
Logged In: YES 
user_id=290026

I found two additional flaws that show up when no 
startElementHandler is set for an element without attributes
(since storeAtts will not be called then):

1) Attributes will not be defaulted, and NS declarations based
on defaulted attributes will not be processed or checked, even
with Jeremy's fix. E.g. this document will pass without error:

<!DOCTYPE doc [
    <!ELEMENT doc (#PCDATA)>
    <!ATTLIST doc
        xmlns:pre CDATA "">
]>
<doc>some data</doc>

2) The element name will be stored but not prepared for 
proper namespace reporting (see ns_triplets), which is
a problem if there is an endElementHandler.

Similar arguments apply for empty elements that have no 
attributes.

So the solution is to always call storeAtts.
This may have a performance impact for the case
when no element handlers are set.

See attached files elmHandlers4.diff/txt.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-25 02:01

Message:
Logged In: YES 
user_id=3066

Committed Karl's latest patch as lib/xmlparse.c 1.106, with
most of his explanation in the commit message.  Portions
need to be incorporated as source comments as well.

Regression tests committed as tests/runtests.c 1.47.

Marked bug as fixed; still need to incorporate additional
source comments, so it remains open, with priority reduced
slightly.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-25 01:17

Message:
Logged In: YES 
user_id=290026

Found already a bug in the fix:

In the case of a start element event, it does not store the
name, which is a problem if there is an endElementHandler.

Revised fix attached as elHandlers2.diif with the description
in elmHandlers2.txt.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 23:49

Message:
Logged In: YES 
user_id=290026

I tested this against the OASIS test-suite and a few large
files with no problems. Hope it passes our suite of regression 
tests as well.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 23:45

Message:
Logged In: YES 
user_id=290026

This patch does not work when no startElementHandler
is set, since then namespace declaration will not be 
processed - a recently documented limitation in Expat.

I have attached a new patch (on top of Jeremy's) which
should fix this, so that namespace declaration will
be processed and checked all the time.

Two files are attached:
- elmHandlers.txt: a brief overview/explanation
- elmHandlers.diff: the patch (against xmlparse.c rev. 1.105)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 01:00

Message:
Logged In: YES 
user_id=3066

Jeremy:  Thanks for the update with regard to XML NS 1.1.  I
agree we don't need to worry about that yet; it's more
important to fix bugs with regard to XML 1.0 and the first
version of the namespaces spec.  See my previous note.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:58

Message:
Logged In: YES 
user_id=3066

Ok, *now* I'm not happy.  I've done my "cvs up", and the
patch doesn't appear to have fixed the problem.  Perhaps I
don't have proper tests yet?  I've attached them to this
issue report.  I expected these tests to pass with current
CVS since Karl checked in Jeremy's patch.

I'll have to deal with this tomorrow; I'm too tired to go
trawling through this just yet.  The patched looked fine on
the surface; did it work for you?

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

Comment By: Jeremy Kloth (jkloth)
Date: 2003-01-24 00:41

Message:
Logged In: YES 
user_id=38980

As far as the bug in the namespace spec goes, they addressed just 
his particular issue with XML NS 1.1.  However that would required XML 
1.1 processing which I'm not sure is something that is needed right 
now (although it is in canidate rec). 

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:20

Message:
Logged In: YES 
user_id=3066

What Karl didn't say was that he checked in the patch as
lib/xmlparse.c revision 1.105.  ;-)  I'll just avoid doing a
"cvs up" until the test is done -- should be soon.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-24 00:08

Message:
Logged In: YES 
user_id=290026

Sorry, Fred.

I jumped the gun - wanted to finish it before going to bed.
It really looks OK, so I don't feel I risked too much.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-24 00:03

Message:
Logged In: YES 
user_id=3066

I think you're right.  I haven't looked at the patch yet,
but the spec is (almost) clear about this.

I will note that I consider this more a bug in the namespace
spec than a desirable feature or constraint to test:  It
makes more sense (to me) to allow the use of xmlns:prefix=''
to "un-declare" the prefix (possibly making it an error of
some sort to un-declare a prefix that doesn't have an active
declaration).  But that's my opinion, not the letter of the
spec.

I'll mark this as accepted (for concept), and work up a test
case before committing anything.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 23:37

Message:
Logged In: YES 
user_id=290026

Yes, it seems the NS specs do not allow a prefix name with 
an empty URI. This patch looks OK to me - if Fred agrees, I 
can commit it. 

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

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

From noreply at sourceforge.net  Mon Jan 27 21:54:37 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 28 00:50:11 2003
Subject: [Expat-bugs] [ expat-Bugs-669861 ] storeRawNames and namespace
	processing
Message-ID: <E18dOhh-0005jX-00@sc8-sf-web4.sourceforge.net>

Bugs item #669861, was opened at 2003-01-17 12:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=669861&group_id=10127

Category: None
Group: None
>Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: Pavel Hlavnicka (pavel_hlavnicka)
Assigned to: Karl Waclawek (kwaclaw)
Summary: storeRawNames and namespace processing

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

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

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

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

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

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

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

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

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

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

Keep a good work

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 00:54

Message:
Logged In: YES 
user_id=3066

As promised, we're closing this as a duplicate.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-20 11:59

Message:
Logged In: YES 
user_id=290026

That's great.

Please let me know if you have any more problems.

If I don't hear from you in the next few days,
I'll close this bug as a duplicate. 

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

Comment By: Pavel Hlavnicka (pavel_hlavnicka)
Date: 2003-01-20 11:00

Message:
Logged In: YES 
user_id=302801

CVS version seems be ok. This entry looks like a duplicate
of  #667511 (but don't trust me too much :)

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

Comment By: Pavel Hlavnicka (pavel_hlavnicka)
Date: 2003-01-20 04:28

Message:
Logged In: YES 
user_id=302801

Bugs you pointed seem be of the similar flavour. Especially
#667511. 

I'd like to try the CVS version, but my system uses older
version of autoconf, and I have got some reasons not to upgrade.

If you want me to test it, please be so nice, and make a
test distribution for me. Sorry and thanks.

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

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

Message:
Logged In: YES 
user_id=290026

We hava a few fixes for storeRawNames in CVS.
Please check bugs #618199 and #667511 if they explain
the behaviour to you.

Before spending more time on it, I recommend you
run with CVS for a while and check if the problem
shows up again.

I also asked the user who reported these bugs first,
and he thinks your problem may be the same.

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

Comment By: Pavel Hlavnicka (pavel_hlavnicka)
Date: 2003-01-17 13:27

Message:
Logged In: YES 
user_id=302801

I'm using 1.95.5. I didn't check CVS, and would have to
check the source, not execution to prove it. The reason for
it is that the error is really hard to reporoduce.

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

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

Message:
Logged In: YES 
user_id=290026

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

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

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

From noreply at sourceforge.net  Mon Jan 27 21:55:52 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 28 00:51:16 2003
Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault: bad API/callback
	interaction
Message-ID: <E18dOiu-0000VX-00@sc8-sf-web1.sourceforge.net>

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

Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: segfault: bad API/callback interaction

Initial Comment:
There is a bad interaction between the call to the
start element handler and the Expat API:  After the
presence of the callback is checked, the addBinding()
function can call XML_SetStartElementHandler(parser,
NULL), after which doContent() will still attempt to
call the start element handler.  This results in a call
to the NULL address, resulting in a memory fault.

This is unlikely to be an issue for applications
written entirely in C, but can reasonably happen when a
wrapper library clears callbacks when an error
condition or exception has been detected.

I've attached a patch and a regression test for this case.


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 00:55

Message:
Logged In: YES 
user_id=3066

Since there have been no objections, this is being closed, 
and marked as fixed.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-21 22:31

Message:
Logged In: YES 
user_id=3066

While I really like the idea that each handler is completely
independent, as the API suggests, I'm not aware of any
real-world use case that requires the namespace callbacks
but not the element boundary callbacks.  Without the use
cases, I think we can live with documented limitations.  As
long as limitations are documented, higher-level layers can
implement the fully-decoupled callbacks model if needed, by
registering "dummy" callbacks as needed to take the place of
application-level callbacks.

Since I've added notes to the documentation about the
limitations relevant to this issue report, I think this is
safe to close if there are no objections in the next day or so.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 14:32

Message:
Logged In: YES 
user_id=290026

The patch passes the OASIS test-suite correctly, but
I am not sure it is worth the extra CPU cycles to make
the namespace declaration handlers truly independent
of the startElementHandler.

Any use cases for that?

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 11:59

Message:
Logged In: YES 
user_id=290026

I have attached a patch (ElmHandlers.diff) that calls
storeAtts whenever any of the attribute related handlers
is called, i.e. :
- startElmHandler, 
- startNamespaceDeclHandler, and
- endNamespaceDeclHandler.

The default handler calls are adjusted appropriately.

This patch should make it possible to have the 
namespace declaration handlers called even when 
no startElementHandlers is set.

Please review. Not tested yet.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-21 11:14

Message:
Logged In: YES 
user_id=3066

Added notes about the limitation in the documentation:
doc/reference.html 1.41

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 10:55

Message:
Logged In: YES 
user_id=290026

I had another look and this looks trickier than I thought.
I suggest we add documentation that states that
the start/endNamespaceDeclHandlers will not be called
when the startElementHandler is not set.

I'll post more details in a follow-up.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-10-08 13:40

Message:
Logged In: YES 
user_id=290026

I am not *that* eager <g>.
You take care of it.

Thanks!

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-10-08 13:36

Message:
Logged In: YES 
user_id=3066

Original patch checked in as lib/xmlparse.c 1.92 and
tests/runtests.c 1.36, before I saw Karl's comments.

Karl:  Yes, we should probably fix things so the namespace
decl handlers can be set independently, as the API suggests.
 I can take care of this, unless you beat me to it.  ;-)

Don't know that it warrants a separate issue report, so I'll
leave this one as fixed but open for now.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-10-08 13:21

Message:
Logged In: YES 
user_id=290026

Yes, verified. To be precise, addBinding() can call back
to startNamespaceDeclHandler() which then allows
the application to clear the startElementHandler.

One comment: storeAtts() is called like this

  if (startElementHandler) {
    result = storeAtts(parser, ...);
    ...
  }

presumably because the attributes should only be
stored if needed for the startElementHandler.
However, storeAtts does double duty by also
processing namespace declarations and calling
startNamespaceDeclHandler().

So, if that handler is set, should then not storeAtts()
be called like this:

  if (startElementHandler || startNamespaceDeclHandler)
  {
    result = storeAtts(parser, ...);
    ...
  }

And, if true, one should then apply this logic to the
other occasions when storeAtts() is called.

Or does it not make sense to set 
startNamespaceDeclHandler when
startElementHandler is cleared?



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

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

From noreply at sourceforge.net  Tue Jan 28 02:44:08 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 28 05:39:41 2003
Subject: [Expat-bugs] [ expat-Bugs-609603 ] v1.95.5 Win32 static lib symbol
	problem
Message-ID: <E18dTDs-0003MJ-00@sc8-sf-web2.sourceforge.net>

Bugs item #609603, was opened at 2002-09-15 18:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=609603&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: v1.95.5 Win32 static lib symbol problem

Initial Comment:
I just switched over to using the Win32 static lib 
version of Expat in my MSVC++ application.

Now, it appears that the following line:

#define _STATIC

is required before

#include "expat.h"

otherwise, the link fails.



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

Comment By: Mike Roskanuk (mikerosky)
Date: 2003-01-28 11:44

Message:
Logged In: YES 
user_id=698797

Sorry - where is that Readme? I can't find it (in 
expat_win32bin_1_95_6.exe). Anyway - IMHO it should be 
mentioned in Doc/reference.html [Building and Installing].


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 21:53

Message:
Logged In: YES 
user_id=290026

The static linking for Windows is documented in
the ReadMe file under the Win32 directory.

But is that enough, or should some documentation
be added elsewhere - at least the fact that the
global macro XML_STATIC needs to be defined?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-23 21:39

Message:
Logged In: YES 
user_id=3066

Static linking on Unix is a non-starter -- every platform
handles all linking differently, and developers hate their
lives if they have to go beyond writing code to actually
linking an application together.  There's nothing
Expat-specific in this sea of misery.

I don't know what a Windows programmer needs to be told, so
someone will have to tell me, or provide a patch.  It sounds
like there's a problem there, but I've no idea offhand if
that's unique to the static Expat libraries, or endemic to
Windows.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-09-15 18:50

Message:
Logged In: YES 
user_id=290026

Either that, or you define _STATIC in the Project Settings.
Have a look at the "elements" demo project, it is
statically linked.

However, I think it is not enough to just have the demo
project, we should document this as well.

I'll assign this to Fred, since the documentation
needs to include static linking instructions for
Unix systems too.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-09-15 18:29

Message:
Logged In: NO 




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

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

From noreply at sourceforge.net  Tue Jan 28 05:21:26 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 28 08:16:50 2003
Subject: [Expat-bugs] [ expat-Bugs-609603 ] v1.95.5 Win32 static lib symbol
	problem
Message-ID: <E18dVg6-00061L-00@sc8-sf-web4.sourceforge.net>

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

>Category: Documentation
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: v1.95.5 Win32 static lib symbol problem

Initial Comment:
I just switched over to using the Win32 static lib 
version of Expat in my MSVC++ application.

Now, it appears that the following line:

#define _STATIC

is required before

#include "expat.h"

otherwise, the link fails.



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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 08:21

Message:
Logged In: YES 
user_id=3066

Looks like that file doesn't get installed by the Windows 
installer; it only exists in the CVS repository.  I'll add the 
information to the general documentation, or add a separate 
HTML file as part of the docs with a link from the main 
reference.html.

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

Comment By: Mike Roskanuk (mikerosky)
Date: 2003-01-28 05:44

Message:
Logged In: YES 
user_id=698797

Sorry - where is that Readme? I can't find it (in 
expat_win32bin_1_95_6.exe). Anyway - IMHO it should be 
mentioned in Doc/reference.html [Building and Installing].


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 15:53

Message:
Logged In: YES 
user_id=290026

The static linking for Windows is documented in
the ReadMe file under the Win32 directory.

But is that enough, or should some documentation
be added elsewhere - at least the fact that the
global macro XML_STATIC needs to be defined?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-23 15:39

Message:
Logged In: YES 
user_id=3066

Static linking on Unix is a non-starter -- every platform
handles all linking differently, and developers hate their
lives if they have to go beyond writing code to actually
linking an application together.  There's nothing
Expat-specific in this sea of misery.

I don't know what a Windows programmer needs to be told, so
someone will have to tell me, or provide a patch.  It sounds
like there's a problem there, but I've no idea offhand if
that's unique to the static Expat libraries, or endemic to
Windows.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-09-15 12:50

Message:
Logged In: YES 
user_id=290026

Either that, or you define _STATIC in the Project Settings.
Have a look at the "elements" demo project, it is
statically linked.

However, I think it is not enough to just have the demo
project, we should document this as well.

I'll assign this to Fred, since the documentation
needs to include static linking instructions for
Unix systems too.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-09-15 12:29

Message:
Logged In: NO 




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

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

From noreply at sourceforge.net  Tue Jan 28 05:58:04 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 28 08:53:15 2003
Subject: [Expat-bugs] [ expat-Bugs-609603 ] v1.95.5 Win32 static lib symbol
	problem
Message-ID: <E18dWFY-0005vB-00@sc8-sf-web3.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: v1.95.5 Win32 static lib symbol problem

Initial Comment:
I just switched over to using the Win32 static lib 
version of Expat in my MSVC++ application.

Now, it appears that the following line:

#define _STATIC

is required before

#include "expat.h"

otherwise, the link fails.



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

Comment By: Mike Roskanuk (mikerosky)
Date: 2003-01-28 14:58

Message:
Logged In: YES 
user_id=698797

Fine. BTW why you decided to use Windows installer, when 
it's "just a few files" a you don't need to do anything with 
system as .dll dependencies, registry modifications etc? 
IMHO .zip archive should be sufficient ...

P.S. FYI: I compiled and use expat on Windows CE 3.0 
with no problem. Thanks 4 good job!


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 14:21

Message:
Logged In: YES 
user_id=3066

Looks like that file doesn't get installed by the Windows 
installer; it only exists in the CVS repository.  I'll add the 
information to the general documentation, or add a separate 
HTML file as part of the docs with a link from the main 
reference.html.

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

Comment By: Mike Roskanuk (mikerosky)
Date: 2003-01-28 11:44

Message:
Logged In: YES 
user_id=698797

Sorry - where is that Readme? I can't find it (in 
expat_win32bin_1_95_6.exe). Anyway - IMHO it should be 
mentioned in Doc/reference.html [Building and Installing].


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 21:53

Message:
Logged In: YES 
user_id=290026

The static linking for Windows is documented in
the ReadMe file under the Win32 directory.

But is that enough, or should some documentation
be added elsewhere - at least the fact that the
global macro XML_STATIC needs to be defined?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-23 21:39

Message:
Logged In: YES 
user_id=3066

Static linking on Unix is a non-starter -- every platform
handles all linking differently, and developers hate their
lives if they have to go beyond writing code to actually
linking an application together.  There's nothing
Expat-specific in this sea of misery.

I don't know what a Windows programmer needs to be told, so
someone will have to tell me, or provide a patch.  It sounds
like there's a problem there, but I've no idea offhand if
that's unique to the static Expat libraries, or endemic to
Windows.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-09-15 18:50

Message:
Logged In: YES 
user_id=290026

Either that, or you define _STATIC in the Project Settings.
Have a look at the "elements" demo project, it is
statically linked.

However, I think it is not enough to just have the demo
project, we should document this as well.

I'll assign this to Fred, since the documentation
needs to include static linking instructions for
Unix systems too.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-09-15 18:29

Message:
Logged In: NO 




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

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

From noreply at sourceforge.net  Tue Jan 28 06:05:20 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 28 09:00:47 2003
Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault: bad API/callback
	interaction
Message-ID: <E18dWMa-0007Lx-00@sc8-sf-web4.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: segfault: bad API/callback interaction

Initial Comment:
There is a bad interaction between the call to the
start element handler and the Expat API:  After the
presence of the callback is checked, the addBinding()
function can call XML_SetStartElementHandler(parser,
NULL), after which doContent() will still attempt to
call the start element handler.  This results in a call
to the NULL address, resulting in a memory fault.

This is unlikely to be an issue for applications
written entirely in C, but can reasonably happen when a
wrapper library clears callbacks when an error
condition or exception has been detected.

I've attached a patch and a regression test for this case.


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-28 09:05

Message:
Logged In: YES 
user_id=290026

Should my newest fix ("always call storeAtts") not make
the handlkers independent? Therefore, should we not 
remove the documentation item about the "limitation"?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 00:55

Message:
Logged In: YES 
user_id=3066

Since there have been no objections, this is being closed, 
and marked as fixed.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-21 22:31

Message:
Logged In: YES 
user_id=3066

While I really like the idea that each handler is completely
independent, as the API suggests, I'm not aware of any
real-world use case that requires the namespace callbacks
but not the element boundary callbacks.  Without the use
cases, I think we can live with documented limitations.  As
long as limitations are documented, higher-level layers can
implement the fully-decoupled callbacks model if needed, by
registering "dummy" callbacks as needed to take the place of
application-level callbacks.

Since I've added notes to the documentation about the
limitations relevant to this issue report, I think this is
safe to close if there are no objections in the next day or so.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 14:32

Message:
Logged In: YES 
user_id=290026

The patch passes the OASIS test-suite correctly, but
I am not sure it is worth the extra CPU cycles to make
the namespace declaration handlers truly independent
of the startElementHandler.

Any use cases for that?

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 11:59

Message:
Logged In: YES 
user_id=290026

I have attached a patch (ElmHandlers.diff) that calls
storeAtts whenever any of the attribute related handlers
is called, i.e. :
- startElmHandler, 
- startNamespaceDeclHandler, and
- endNamespaceDeclHandler.

The default handler calls are adjusted appropriately.

This patch should make it possible to have the 
namespace declaration handlers called even when 
no startElementHandlers is set.

Please review. Not tested yet.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-21 11:14

Message:
Logged In: YES 
user_id=3066

Added notes about the limitation in the documentation:
doc/reference.html 1.41

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 10:55

Message:
Logged In: YES 
user_id=290026

I had another look and this looks trickier than I thought.
I suggest we add documentation that states that
the start/endNamespaceDeclHandlers will not be called
when the startElementHandler is not set.

I'll post more details in a follow-up.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-10-08 13:40

Message:
Logged In: YES 
user_id=290026

I am not *that* eager <g>.
You take care of it.

Thanks!

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-10-08 13:36

Message:
Logged In: YES 
user_id=3066

Original patch checked in as lib/xmlparse.c 1.92 and
tests/runtests.c 1.36, before I saw Karl's comments.

Karl:  Yes, we should probably fix things so the namespace
decl handlers can be set independently, as the API suggests.
 I can take care of this, unless you beat me to it.  ;-)

Don't know that it warrants a separate issue report, so I'll
leave this one as fixed but open for now.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-10-08 13:21

Message:
Logged In: YES 
user_id=290026

Yes, verified. To be precise, addBinding() can call back
to startNamespaceDeclHandler() which then allows
the application to clear the startElementHandler.

One comment: storeAtts() is called like this

  if (startElementHandler) {
    result = storeAtts(parser, ...);
    ...
  }

presumably because the attributes should only be
stored if needed for the startElementHandler.
However, storeAtts does double duty by also
processing namespace declarations and calling
startNamespaceDeclHandler().

So, if that handler is set, should then not storeAtts()
be called like this:

  if (startElementHandler || startNamespaceDeclHandler)
  {
    result = storeAtts(parser, ...);
    ...
  }

And, if true, one should then apply this logic to the
other occasions when storeAtts() is called.

Or does it not make sense to set 
startNamespaceDeclHandler when
startElementHandler is cleared?



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

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

From noreply at sourceforge.net  Tue Jan 28 07:21:30 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 28 10:17:01 2003
Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault: bad API/callback
	interaction
Message-ID: <E18dXYI-00070Q-00@sc8-sf-web2.sourceforge.net>

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

>Category: Documentation
>Group: Test Required
>Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: segfault: bad API/callback interaction

Initial Comment:
There is a bad interaction between the call to the
start element handler and the Expat API:  After the
presence of the callback is checked, the addBinding()
function can call XML_SetStartElementHandler(parser,
NULL), after which doContent() will still attempt to
call the start element handler.  This results in a call
to the NULL address, resulting in a memory fault.

This is unlikely to be an issue for applications
written entirely in C, but can reasonably happen when a
wrapper library clears callbacks when an error
condition or exception has been detected.

I've attached a patch and a regression test for this case.


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 10:21

Message:
Logged In: YES 
user_id=3066

It probably does.  There should be a bug report on the
documentation, to which I'll respond "we need more tests to
check this", and a year from now we'll decide the lack of
thoses tests won't hold up the next bugfix release.

Or maybe I'll just write thoses tests.  ;-)

For now, re-opening this as a documentation bug (regarding
documented limitations that should no longer exist), and
marked if "Test Required".  Still assigned to me.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-28 09:05

Message:
Logged In: YES 
user_id=290026

Should my newest fix ("always call storeAtts") not make
the handlkers independent? Therefore, should we not 
remove the documentation item about the "limitation"?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 00:55

Message:
Logged In: YES 
user_id=3066

Since there have been no objections, this is being closed, 
and marked as fixed.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-21 22:31

Message:
Logged In: YES 
user_id=3066

While I really like the idea that each handler is completely
independent, as the API suggests, I'm not aware of any
real-world use case that requires the namespace callbacks
but not the element boundary callbacks.  Without the use
cases, I think we can live with documented limitations.  As
long as limitations are documented, higher-level layers can
implement the fully-decoupled callbacks model if needed, by
registering "dummy" callbacks as needed to take the place of
application-level callbacks.

Since I've added notes to the documentation about the
limitations relevant to this issue report, I think this is
safe to close if there are no objections in the next day or so.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 14:32

Message:
Logged In: YES 
user_id=290026

The patch passes the OASIS test-suite correctly, but
I am not sure it is worth the extra CPU cycles to make
the namespace declaration handlers truly independent
of the startElementHandler.

Any use cases for that?

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 11:59

Message:
Logged In: YES 
user_id=290026

I have attached a patch (ElmHandlers.diff) that calls
storeAtts whenever any of the attribute related handlers
is called, i.e. :
- startElmHandler, 
- startNamespaceDeclHandler, and
- endNamespaceDeclHandler.

The default handler calls are adjusted appropriately.

This patch should make it possible to have the 
namespace declaration handlers called even when 
no startElementHandlers is set.

Please review. Not tested yet.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-21 11:14

Message:
Logged In: YES 
user_id=3066

Added notes about the limitation in the documentation:
doc/reference.html 1.41

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 10:55

Message:
Logged In: YES 
user_id=290026

I had another look and this looks trickier than I thought.
I suggest we add documentation that states that
the start/endNamespaceDeclHandlers will not be called
when the startElementHandler is not set.

I'll post more details in a follow-up.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-10-08 13:40

Message:
Logged In: YES 
user_id=290026

I am not *that* eager <g>.
You take care of it.

Thanks!

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-10-08 13:36

Message:
Logged In: YES 
user_id=3066

Original patch checked in as lib/xmlparse.c 1.92 and
tests/runtests.c 1.36, before I saw Karl's comments.

Karl:  Yes, we should probably fix things so the namespace
decl handlers can be set independently, as the API suggests.
 I can take care of this, unless you beat me to it.  ;-)

Don't know that it warrants a separate issue report, so I'll
leave this one as fixed but open for now.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-10-08 13:21

Message:
Logged In: YES 
user_id=290026

Yes, verified. To be precise, addBinding() can call back
to startNamespaceDeclHandler() which then allows
the application to clear the startElementHandler.

One comment: storeAtts() is called like this

  if (startElementHandler) {
    result = storeAtts(parser, ...);
    ...
  }

presumably because the attributes should only be
stored if needed for the startElementHandler.
However, storeAtts does double duty by also
processing namespace declarations and calling
startNamespaceDeclHandler().

So, if that handler is set, should then not storeAtts()
be called like this:

  if (startElementHandler || startNamespaceDeclHandler)
  {
    result = storeAtts(parser, ...);
    ...
  }

And, if true, one should then apply this logic to the
other occasions when storeAtts() is called.

Or does it not make sense to set 
startNamespaceDeclHandler when
startElementHandler is cleared?



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

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

From noreply at sourceforge.net  Tue Jan 28 07:24:06 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 28 10:19:27 2003
Subject: [Expat-bugs] [ expat-Bugs-676131 ] Need documentation for migration
	path.
Message-ID: <E18dXao-0002N7-00@sc8-sf-web4.sourceforge.net>

Bugs item #676131, was opened at 2003-01-28 10:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676131&group_id=10127

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Need documentation for migration path.

Initial Comment:
There needs to be more documentation for people
upgrading from older versions of Expat.  This includes
(but is not limited to!) the introduction of the
XML_Status enumeration and annotations in the
documentation for when each API construct was added to
the library.

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

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

From noreply at sourceforge.net  Tue Jan 28 07:38:24 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 28 10:35:01 2003
Subject: [Expat-bugs] [ expat-Bugs-609603 ] v1.95.5 Win32 static lib symbol
	problem
Message-ID: <E18dXoe-00036S-00@sc8-sf-web4.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: v1.95.5 Win32 static lib symbol problem

Initial Comment:
I just switched over to using the Win32 static lib 
version of Expat in my MSVC++ application.

Now, it appears that the following line:

#define _STATIC

is required before

#include "expat.h"

otherwise, the link fails.



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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 10:38

Message:
Logged In: YES 
user_id=3066

Added win32/README.txt to the Windows installation in
win32/expat.iss 1.16.  I still intend to me the other
documentation changes described in earlier comments.

Glad to hear things work on CE now!

I went with the installer mostly because I figured that's
how things seem to be done on Windows, but I'm not really a
"Windows person" myself.  There is an aspect of Expat that
non-programmers might install it for, and that's the "xmlwf"
application, but I probably don't do the right thing to make
that useful out of the box now.

For me, the real question is "What would Expat users on
Windows expect?"  I'll provide whichever makes the most
sense; I can provide both if that's the right thing.  (This
might make sense since xmlwf is targetted to a larger
audience than just developers.)

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

Comment By: Mike Roskanuk (mikerosky)
Date: 2003-01-28 08:58

Message:
Logged In: YES 
user_id=698797

Fine. BTW why you decided to use Windows installer, when 
it's "just a few files" a you don't need to do anything with 
system as .dll dependencies, registry modifications etc? 
IMHO .zip archive should be sufficient ...

P.S. FYI: I compiled and use expat on Windows CE 3.0 
with no problem. Thanks 4 good job!


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 08:21

Message:
Logged In: YES 
user_id=3066

Looks like that file doesn't get installed by the Windows 
installer; it only exists in the CVS repository.  I'll add the 
information to the general documentation, or add a separate 
HTML file as part of the docs with a link from the main 
reference.html.

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

Comment By: Mike Roskanuk (mikerosky)
Date: 2003-01-28 05:44

Message:
Logged In: YES 
user_id=698797

Sorry - where is that Readme? I can't find it (in 
expat_win32bin_1_95_6.exe). Anyway - IMHO it should be 
mentioned in Doc/reference.html [Building and Installing].


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 15:53

Message:
Logged In: YES 
user_id=290026

The static linking for Windows is documented in
the ReadMe file under the Win32 directory.

But is that enough, or should some documentation
be added elsewhere - at least the fact that the
global macro XML_STATIC needs to be defined?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-23 15:39

Message:
Logged In: YES 
user_id=3066

Static linking on Unix is a non-starter -- every platform
handles all linking differently, and developers hate their
lives if they have to go beyond writing code to actually
linking an application together.  There's nothing
Expat-specific in this sea of misery.

I don't know what a Windows programmer needs to be told, so
someone will have to tell me, or provide a patch.  It sounds
like there's a problem there, but I've no idea offhand if
that's unique to the static Expat libraries, or endemic to
Windows.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-09-15 12:50

Message:
Logged In: YES 
user_id=290026

Either that, or you define _STATIC in the Project Settings.
Have a look at the "elements" demo project, it is
statically linked.

However, I think it is not enough to just have the demo
project, we should document this as well.

I'll assign this to Fred, since the documentation
needs to include static linking instructions for
Unix systems too.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-09-15 12:29

Message:
Logged In: NO 




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

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

From noreply at sourceforge.net  Tue Jan 28 09:41:06 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 28 12:37:23 2003
Subject: [Expat-bugs] [ expat-Bugs-609603 ] v1.95.5 Win32 static lib symbol
	problem
Message-ID: <E18dZjO-00012p-00@sc8-sf-web4.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: v1.95.5 Win32 static lib symbol problem

Initial Comment:
I just switched over to using the Win32 static lib 
version of Expat in my MSVC++ application.

Now, it appears that the following line:

#define _STATIC

is required before

#include "expat.h"

otherwise, the link fails.



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

Comment By: Mike Roskanuk (mikerosky)
Date: 2003-01-28 18:41

Message:
Logged In: YES 
user_id=698797

Generally, winstaller is used by similiar way as rpm and 
other pkg systems, it shoud take care of dependencies 
(correct versions of .dlls), deploy in files, write to windows 
registry etc. For sources only is IMHO better to use .zip,
same as it's .gzipped for unix/linux world.
Of course - why not to offer both. Or you can offer zip/rar 
self-extract archive. It could be "golden middle path" (jeez i 
hope this idiom exist in english, too ;-)


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 16:38

Message:
Logged In: YES 
user_id=3066

Added win32/README.txt to the Windows installation in
win32/expat.iss 1.16.  I still intend to me the other
documentation changes described in earlier comments.

Glad to hear things work on CE now!

I went with the installer mostly because I figured that's
how things seem to be done on Windows, but I'm not really a
"Windows person" myself.  There is an aspect of Expat that
non-programmers might install it for, and that's the "xmlwf"
application, but I probably don't do the right thing to make
that useful out of the box now.

For me, the real question is "What would Expat users on
Windows expect?"  I'll provide whichever makes the most
sense; I can provide both if that's the right thing.  (This
might make sense since xmlwf is targetted to a larger
audience than just developers.)

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

Comment By: Mike Roskanuk (mikerosky)
Date: 2003-01-28 14:58

Message:
Logged In: YES 
user_id=698797

Fine. BTW why you decided to use Windows installer, when 
it's "just a few files" a you don't need to do anything with 
system as .dll dependencies, registry modifications etc? 
IMHO .zip archive should be sufficient ...

P.S. FYI: I compiled and use expat on Windows CE 3.0 
with no problem. Thanks 4 good job!


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 14:21

Message:
Logged In: YES 
user_id=3066

Looks like that file doesn't get installed by the Windows 
installer; it only exists in the CVS repository.  I'll add the 
information to the general documentation, or add a separate 
HTML file as part of the docs with a link from the main 
reference.html.

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

Comment By: Mike Roskanuk (mikerosky)
Date: 2003-01-28 11:44

Message:
Logged In: YES 
user_id=698797

Sorry - where is that Readme? I can't find it (in 
expat_win32bin_1_95_6.exe). Anyway - IMHO it should be 
mentioned in Doc/reference.html [Building and Installing].


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 21:53

Message:
Logged In: YES 
user_id=290026

The static linking for Windows is documented in
the ReadMe file under the Win32 directory.

But is that enough, or should some documentation
be added elsewhere - at least the fact that the
global macro XML_STATIC needs to be defined?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-23 21:39

Message:
Logged In: YES 
user_id=3066

Static linking on Unix is a non-starter -- every platform
handles all linking differently, and developers hate their
lives if they have to go beyond writing code to actually
linking an application together.  There's nothing
Expat-specific in this sea of misery.

I don't know what a Windows programmer needs to be told, so
someone will have to tell me, or provide a patch.  It sounds
like there's a problem there, but I've no idea offhand if
that's unique to the static Expat libraries, or endemic to
Windows.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-09-15 18:50

Message:
Logged In: YES 
user_id=290026

Either that, or you define _STATIC in the Project Settings.
Have a look at the "elements" demo project, it is
statically linked.

However, I think it is not enough to just have the demo
project, we should document this as well.

I'll assign this to Fred, since the documentation
needs to include static linking instructions for
Unix systems too.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-09-15 18:29

Message:
Logged In: NO 




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

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

From noreply at sourceforge.net  Tue Jan 28 09:53:18 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 28 12:48:29 2003
Subject: [Expat-bugs] [ expat-Bugs-609603 ] v1.95.5 Win32 static lib symbol
	problem
Message-ID: <E18dZvC-0001fv-00@sc8-sf-web3.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: v1.95.5 Win32 static lib symbol problem

Initial Comment:
I just switched over to using the Win32 static lib 
version of Expat in my MSVC++ application.

Now, it appears that the following line:

#define _STATIC

is required before

#include "expat.h"

otherwise, the link fails.



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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 12:53

Message:
Logged In: YES 
user_id=3066

The current installer includes both libraries and the xmlwf
application, but just drops them into place.  It also
contains sources.

Perhaps the right thing for someone who only wants sources
is to grab the .tar.gz package?  Most of the good archive
handlers used for ZIP files also handle .tar.gz quite well
(I use WinZip for these on Windows, myself).

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

Comment By: Mike Roskanuk (mikerosky)
Date: 2003-01-28 12:41

Message:
Logged In: YES 
user_id=698797

Generally, winstaller is used by similiar way as rpm and 
other pkg systems, it shoud take care of dependencies 
(correct versions of .dlls), deploy in files, write to windows 
registry etc. For sources only is IMHO better to use .zip,
same as it's .gzipped for unix/linux world.
Of course - why not to offer both. Or you can offer zip/rar 
self-extract archive. It could be "golden middle path" (jeez i 
hope this idiom exist in english, too ;-)


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 10:38

Message:
Logged In: YES 
user_id=3066

Added win32/README.txt to the Windows installation in
win32/expat.iss 1.16.  I still intend to me the other
documentation changes described in earlier comments.

Glad to hear things work on CE now!

I went with the installer mostly because I figured that's
how things seem to be done on Windows, but I'm not really a
"Windows person" myself.  There is an aspect of Expat that
non-programmers might install it for, and that's the "xmlwf"
application, but I probably don't do the right thing to make
that useful out of the box now.

For me, the real question is "What would Expat users on
Windows expect?"  I'll provide whichever makes the most
sense; I can provide both if that's the right thing.  (This
might make sense since xmlwf is targetted to a larger
audience than just developers.)

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

Comment By: Mike Roskanuk (mikerosky)
Date: 2003-01-28 08:58

Message:
Logged In: YES 
user_id=698797

Fine. BTW why you decided to use Windows installer, when 
it's "just a few files" a you don't need to do anything with 
system as .dll dependencies, registry modifications etc? 
IMHO .zip archive should be sufficient ...

P.S. FYI: I compiled and use expat on Windows CE 3.0 
with no problem. Thanks 4 good job!


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 08:21

Message:
Logged In: YES 
user_id=3066

Looks like that file doesn't get installed by the Windows 
installer; it only exists in the CVS repository.  I'll add the 
information to the general documentation, or add a separate 
HTML file as part of the docs with a link from the main 
reference.html.

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

Comment By: Mike Roskanuk (mikerosky)
Date: 2003-01-28 05:44

Message:
Logged In: YES 
user_id=698797

Sorry - where is that Readme? I can't find it (in 
expat_win32bin_1_95_6.exe). Anyway - IMHO it should be 
mentioned in Doc/reference.html [Building and Installing].


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 15:53

Message:
Logged In: YES 
user_id=290026

The static linking for Windows is documented in
the ReadMe file under the Win32 directory.

But is that enough, or should some documentation
be added elsewhere - at least the fact that the
global macro XML_STATIC needs to be defined?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-23 15:39

Message:
Logged In: YES 
user_id=3066

Static linking on Unix is a non-starter -- every platform
handles all linking differently, and developers hate their
lives if they have to go beyond writing code to actually
linking an application together.  There's nothing
Expat-specific in this sea of misery.

I don't know what a Windows programmer needs to be told, so
someone will have to tell me, or provide a patch.  It sounds
like there's a problem there, but I've no idea offhand if
that's unique to the static Expat libraries, or endemic to
Windows.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-09-15 12:50

Message:
Logged In: YES 
user_id=290026

Either that, or you define _STATIC in the Project Settings.
Have a look at the "elements" demo project, it is
statically linked.

However, I think it is not enough to just have the demo
project, we should document this as well.

I'll assign this to Fred, since the documentation
needs to include static linking instructions for
Unix systems too.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-09-15 12:29

Message:
Logged In: NO 




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

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

From noreply at sourceforge.net  Tue Jan 28 10:12:01 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jan 28 13:07:26 2003
Subject: [Expat-bugs] [ expat-Bugs-609603 ] v1.95.5 Win32 static lib symbol
	problem
Message-ID: <E18daDJ-00029L-00@sc8-sf-web4.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: v1.95.5 Win32 static lib symbol problem

Initial Comment:
I just switched over to using the Win32 static lib 
version of Expat in my MSVC++ application.

Now, it appears that the following line:

#define _STATIC

is required before

#include "expat.h"

otherwise, the link fails.



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

Comment By: Mike Roskanuk (mikerosky)
Date: 2003-01-28 19:12

Message:
Logged In: YES 
user_id=698797

That's true, i have no problem with .tar.gz. I just ment 
Win32 version differs ... (usually it's true for code ported to 
win32). Don't worry about it, it was just an idea.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 18:53

Message:
Logged In: YES 
user_id=3066

The current installer includes both libraries and the xmlwf
application, but just drops them into place.  It also
contains sources.

Perhaps the right thing for someone who only wants sources
is to grab the .tar.gz package?  Most of the good archive
handlers used for ZIP files also handle .tar.gz quite well
(I use WinZip for these on Windows, myself).

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

Comment By: Mike Roskanuk (mikerosky)
Date: 2003-01-28 18:41

Message:
Logged In: YES 
user_id=698797

Generally, winstaller is used by similiar way as rpm and 
other pkg systems, it shoud take care of dependencies 
(correct versions of .dlls), deploy in files, write to windows 
registry etc. For sources only is IMHO better to use .zip,
same as it's .gzipped for unix/linux world.
Of course - why not to offer both. Or you can offer zip/rar 
self-extract archive. It could be "golden middle path" (jeez i 
hope this idiom exist in english, too ;-)


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 16:38

Message:
Logged In: YES 
user_id=3066

Added win32/README.txt to the Windows installation in
win32/expat.iss 1.16.  I still intend to me the other
documentation changes described in earlier comments.

Glad to hear things work on CE now!

I went with the installer mostly because I figured that's
how things seem to be done on Windows, but I'm not really a
"Windows person" myself.  There is an aspect of Expat that
non-programmers might install it for, and that's the "xmlwf"
application, but I probably don't do the right thing to make
that useful out of the box now.

For me, the real question is "What would Expat users on
Windows expect?"  I'll provide whichever makes the most
sense; I can provide both if that's the right thing.  (This
might make sense since xmlwf is targetted to a larger
audience than just developers.)

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

Comment By: Mike Roskanuk (mikerosky)
Date: 2003-01-28 14:58

Message:
Logged In: YES 
user_id=698797

Fine. BTW why you decided to use Windows installer, when 
it's "just a few files" a you don't need to do anything with 
system as .dll dependencies, registry modifications etc? 
IMHO .zip archive should be sufficient ...

P.S. FYI: I compiled and use expat on Windows CE 3.0 
with no problem. Thanks 4 good job!


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 14:21

Message:
Logged In: YES 
user_id=3066

Looks like that file doesn't get installed by the Windows 
installer; it only exists in the CVS repository.  I'll add the 
information to the general documentation, or add a separate 
HTML file as part of the docs with a link from the main 
reference.html.

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

Comment By: Mike Roskanuk (mikerosky)
Date: 2003-01-28 11:44

Message:
Logged In: YES 
user_id=698797

Sorry - where is that Readme? I can't find it (in 
expat_win32bin_1_95_6.exe). Anyway - IMHO it should be 
mentioned in Doc/reference.html [Building and Installing].


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-23 21:53

Message:
Logged In: YES 
user_id=290026

The static linking for Windows is documented in
the ReadMe file under the Win32 directory.

But is that enough, or should some documentation
be added elsewhere - at least the fact that the
global macro XML_STATIC needs to be defined?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-23 21:39

Message:
Logged In: YES 
user_id=3066

Static linking on Unix is a non-starter -- every platform
handles all linking differently, and developers hate their
lives if they have to go beyond writing code to actually
linking an application together.  There's nothing
Expat-specific in this sea of misery.

I don't know what a Windows programmer needs to be told, so
someone will have to tell me, or provide a patch.  It sounds
like there's a problem there, but I've no idea offhand if
that's unique to the static Expat libraries, or endemic to
Windows.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2002-09-15 18:50

Message:
Logged In: YES 
user_id=290026

Either that, or you define _STATIC in the Project Settings.
Have a look at the "elements" demo project, it is
statically linked.

However, I think it is not enough to just have the demo
project, we should document this as well.

I'll assign this to Fred, since the documentation
needs to include static linking instructions for
Unix systems too.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-09-15 18:29

Message:
Logged In: NO 




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

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

From noreply at sourceforge.net  Wed Jan 29 07:37:34 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jan 29 10:32:34 2003
Subject: [Expat-bugs] [ expat-Bugs-676844 ] expat.h compile error
Message-ID: <E18duHO-0003ft-00@sc8-sf-web3.sourceforge.net>

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

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

Initial Comment:
c++ -DHAVE_CONFIG_H -I. -I. -I../../autocfg -g -O2 -c
context.cpp  -fPIC -DPIC -o .libs/context.lo
In file included from parser.h:45,
                 from guard.h:143,
                 from context.cpp:45:
/usr/include/expat.h:657: use of enum `XML_Status'
without previous declaration
/usr/include/expat.h:736: multiple definition of `enum
XML_Status'


when building sablotron.

Hand editing the file to place the def of enum
XML_Status before any references to it fixes the problem.

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

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

From noreply at sourceforge.net  Wed Jan 29 07:51:16 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jan 29 10:46:37 2003
Subject: [Expat-bugs] [ expat-Bugs-676844 ] expat.h compile error
Message-ID: <E18duUe-0005m1-00@sc8-sf-web4.sourceforge.net>

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

Category: Build control
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: expat.h compile error

Initial Comment:
c++ -DHAVE_CONFIG_H -I. -I. -I../../autocfg -g -O2 -c
context.cpp  -fPIC -DPIC -o .libs/context.lo
In file included from parser.h:45,
                 from guard.h:143,
                 from context.cpp:45:
/usr/include/expat.h:657: use of enum `XML_Status'
without previous declaration
/usr/include/expat.h:736: multiple definition of `enum
XML_Status'


when building sablotron.

Hand editing the file to place the def of enum
XML_Status before any references to it fixes the problem.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-29 10:51

Message:
Logged In: YES 
user_id=290026

So far only gcc3.2 has complained.
Not sure if this is a bug, since most compilers accept it,
but it has been fixed in CVS already anyway.

Set resolution status to fixed, but leave open.
There may be other users who would report this as a bug
and I want them to see the open report instead of 
having duplicates created.

Assigned to Fred - since he may know more about
whether this truly is a bug.

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

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

From noreply at sourceforge.net  Wed Jan 29 09:57:38 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jan 29 12:52:36 2003
Subject: [Expat-bugs] [ expat-Bugs-676926 ] memory leak in
	xmlparse.c::doProlog()
Message-ID: <E18dwSw-0004T7-00@sc8-sf-web3.sourceforge.net>

Bugs item #676926, was opened at 2003-01-29 12:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676926&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: memory leak in xmlparse.c::doProlog()

Initial Comment:
As of now, 2003/1/29, there is a memory leak in
xmlparse.c::doProlog() line 3979.

The XML_Content is dynamically allocated, but never
freed in the block.  The lifetime of the variable
content is not clear.  It is passed to
elementDeclHandler().  Does content need to be dynamic,
or can it be a local (stack) variable?  Does
elementDeclHandler() take ownership of content?

I can make the change in Python (which is where this
problem was found from test_minidom).

20 bytes in 1 blocks are definitely lost in loss record
2 of 15
  at 0x4015D480: malloc (vg_clientfuncs.c:100)
doProlog (python/dist/src/Modules/expat/xmlparse.c:3979)
prologProcessor
(python/dist/src/Modules/expat/xmlparse.c:3185)
prologInitProcessor
(python/dist/src/Modules/expat/xmlparse.c:3016)
XML_ParseBuffer
(python/dist/src/Modules/expat/xmlparse.c:1439)
XML_Parse (python/dist/src/Modules/expat/xmlparse.c:1427)
xmlparse_Parse (python/dist/src/Modules/pyexpat.c:853)


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

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

From noreply at sourceforge.net  Wed Jan 29 10:44:49 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jan 29 13:40:00 2003
Subject: [Expat-bugs] [ expat-Bugs-676844 ] expat.h compile error: enum
	XML_Status
Message-ID: <E18dxCb-0005Up-00@sc8-sf-web4.sourceforge.net>

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

Category: Build control
Group: None
Status: Open
Resolution: Fixed
>Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: expat.h compile error: enum XML_Status

Initial Comment:
c++ -DHAVE_CONFIG_H -I. -I. -I../../autocfg -g -O2 -c
context.cpp  -fPIC -DPIC -o .libs/context.lo
In file included from parser.h:45,
                 from guard.h:143,
                 from context.cpp:45:
/usr/include/expat.h:657: use of enum `XML_Status'
without previous declaration
/usr/include/expat.h:736: multiple definition of `enum
XML_Status'


when building sablotron.

Hand editing the file to place the def of enum
XML_Status before any references to it fixes the problem.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-29 13:44

Message:
Logged In: YES 
user_id=3066

I've not checked the C89 standard yet, but Expat 1.95.6 is 
certainly dodgy in this case.  ;-(  The first draft of the C spec I 
found online certainly seemed to imply that any use of an 
incomplete enum is not allowed; I'm not likely to go out and 
buy a copy of the final spec to check further.  ;-)

As noted, this has been fixed in CVS.  Fixed the summary to 
better indicate what this report is about, and lowered the 
priority to get it out of the way for maintainers.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-29 10:51

Message:
Logged In: YES 
user_id=290026

So far only gcc3.2 has complained.
Not sure if this is a bug, since most compilers accept it,
but it has been fixed in CVS already anyway.

Set resolution status to fixed, but leave open.
There may be other users who would report this as a bug
and I want them to see the open report instead of 
having duplicates created.

Assigned to Fred - since he may know more about
whether this truly is a bug.

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

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

From noreply at sourceforge.net  Wed Jan 29 10:56:00 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jan 29 13:51:21 2003
Subject: [Expat-bugs] [ expat-Bugs-676926 ] memory leak in
	xmlparse.c::doProlog()
Message-ID: <E18dxNQ-0000y7-00@sc8-sf-web2.sourceforge.net>

Bugs item #676926, was opened at 2003-01-29 12:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676926&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
>Priority: 9
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: memory leak in xmlparse.c::doProlog()

Initial Comment:
As of now, 2003/1/29, there is a memory leak in
xmlparse.c::doProlog() line 3979.

The XML_Content is dynamically allocated, but never
freed in the block.  The lifetime of the variable
content is not clear.  It is passed to
elementDeclHandler().  Does content need to be dynamic,
or can it be a local (stack) variable?  Does
elementDeclHandler() take ownership of content?

I can make the change in Python (which is where this
problem was found from test_minidom).

20 bytes in 1 blocks are definitely lost in loss record
2 of 15
  at 0x4015D480: malloc (vg_clientfuncs.c:100)
doProlog (python/dist/src/Modules/expat/xmlparse.c:3979)
prologProcessor
(python/dist/src/Modules/expat/xmlparse.c:3185)
prologInitProcessor
(python/dist/src/Modules/expat/xmlparse.c:3016)
XML_ParseBuffer
(python/dist/src/Modules/expat/xmlparse.c:1439)
XML_Parse (python/dist/src/Modules/expat/xmlparse.c:1427)
xmlparse_Parse (python/dist/src/Modules/pyexpat.c:853)


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

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

From noreply at sourceforge.net  Wed Jan 29 10:59:17 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jan 29 13:54:27 2003
Subject: [Expat-bugs] [ expat-Bugs-676926 ] memory leak in
	xmlparse.c::doProlog()
Message-ID: <E18dxQb-0007rd-00@sc8-sf-web1.sourceforge.net>

Bugs item #676926, was opened at 2003-01-29 12:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676926&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: memory leak in xmlparse.c::doProlog()

Initial Comment:
As of now, 2003/1/29, there is a memory leak in
xmlparse.c::doProlog() line 3979.

The XML_Content is dynamically allocated, but never
freed in the block.  The lifetime of the variable
content is not clear.  It is passed to
elementDeclHandler().  Does content need to be dynamic,
or can it be a local (stack) variable?  Does
elementDeclHandler() take ownership of content?

I can make the change in Python (which is where this
problem was found from test_minidom).

20 bytes in 1 blocks are definitely lost in loss record
2 of 15
  at 0x4015D480: malloc (vg_clientfuncs.c:100)
doProlog (python/dist/src/Modules/expat/xmlparse.c:3979)
prologProcessor
(python/dist/src/Modules/expat/xmlparse.c:3185)
prologInitProcessor
(python/dist/src/Modules/expat/xmlparse.c:3016)
XML_ParseBuffer
(python/dist/src/Modules/expat/xmlparse.c:1439)
XML_Parse (python/dist/src/Modules/expat/xmlparse.c:1427)
xmlparse_Parse (python/dist/src/Modules/pyexpat.c:853)


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-29 13:59

Message:
Logged In: YES 
user_id=3066

Oops, didn't mean to set the priority *that* high; it's a leak, 
not a segfault!

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

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

From noreply at sourceforge.net  Wed Jan 29 11:03:56 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jan 29 13:58:55 2003
Subject: [Expat-bugs] [ expat-Bugs-676926 ] memory leak in
	xmlparse.c::doProlog()
Message-ID: <E18dxV6-0007eo-00@sc8-sf-web3.sourceforge.net>

Bugs item #676926, was opened at 2003-01-29 12:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676926&group_id=10127

Category: None
>Group: Not a Bug
Status: Open
>Resolution: Rejected
>Priority: 9
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: memory leak in xmlparse.c::doProlog()

Initial Comment:
As of now, 2003/1/29, there is a memory leak in
xmlparse.c::doProlog() line 3979.

The XML_Content is dynamically allocated, but never
freed in the block.  The lifetime of the variable
content is not clear.  It is passed to
elementDeclHandler().  Does content need to be dynamic,
or can it be a local (stack) variable?  Does
elementDeclHandler() take ownership of content?

I can make the change in Python (which is where this
problem was found from test_minidom).

20 bytes in 1 blocks are definitely lost in loss record
2 of 15
  at 0x4015D480: malloc (vg_clientfuncs.c:100)
doProlog (python/dist/src/Modules/expat/xmlparse.c:3979)
prologProcessor
(python/dist/src/Modules/expat/xmlparse.c:3185)
prologInitProcessor
(python/dist/src/Modules/expat/xmlparse.c:3016)
XML_ParseBuffer
(python/dist/src/Modules/expat/xmlparse.c:1439)
XML_Parse (python/dist/src/Modules/expat/xmlparse.c:1427)
xmlparse_Parse (python/dist/src/Modules/pyexpat.c:853)


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-29 14:03

Message:
Logged In: YES 
user_id=290026

The content model needs to be freed by the application,
which is documented in reference.html.

We added a new API call in the current release,
XML_FreeContentModel, to make it easier for
non-C languages to free the content model
passed to the elemenDeclHandler.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-29 13:59

Message:
Logged In: YES 
user_id=3066

Oops, didn't mean to set the priority *that* high; it's a leak, 
not a segfault!

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

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

From noreply at sourceforge.net  Wed Jan 29 11:05:16 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jan 29 14:00:16 2003
Subject: [Expat-bugs] [ expat-Bugs-676926 ] memory leak in
	xmlparse.c::doProlog()
Message-ID: <E18dxWO-0007mI-00@sc8-sf-web3.sourceforge.net>

Bugs item #676926, was opened at 2003-01-29 12:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676926&group_id=10127

Category: None
Group: Not a Bug
Status: Open
Resolution: Rejected
>Priority: 3
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: memory leak in xmlparse.c::doProlog()

Initial Comment:
As of now, 2003/1/29, there is a memory leak in
xmlparse.c::doProlog() line 3979.

The XML_Content is dynamically allocated, but never
freed in the block.  The lifetime of the variable
content is not clear.  It is passed to
elementDeclHandler().  Does content need to be dynamic,
or can it be a local (stack) variable?  Does
elementDeclHandler() take ownership of content?

I can make the change in Python (which is where this
problem was found from test_minidom).

20 bytes in 1 blocks are definitely lost in loss record
2 of 15
  at 0x4015D480: malloc (vg_clientfuncs.c:100)
doProlog (python/dist/src/Modules/expat/xmlparse.c:3979)
prologProcessor
(python/dist/src/Modules/expat/xmlparse.c:3185)
prologInitProcessor
(python/dist/src/Modules/expat/xmlparse.c:3016)
XML_ParseBuffer
(python/dist/src/Modules/expat/xmlparse.c:1439)
XML_Parse (python/dist/src/Modules/expat/xmlparse.c:1427)
xmlparse_Parse (python/dist/src/Modules/pyexpat.c:853)


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-29 14:03

Message:
Logged In: YES 
user_id=290026

The content model needs to be freed by the application,
which is documented in reference.html.

We added a new API call in the current release,
XML_FreeContentModel, to make it easier for
non-C languages to free the content model
passed to the elemenDeclHandler.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-29 13:59

Message:
Logged In: YES 
user_id=3066

Oops, didn't mean to set the priority *that* high; it's a leak, 
not a segfault!

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

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

From noreply at sourceforge.net  Wed Jan 29 11:07:59 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jan 29 14:03:18 2003
Subject: [Expat-bugs] [ expat-Bugs-676926 ] memory leak in
	xmlparse.c::doProlog()
Message-ID: <E18dxZ1-0001dF-00@sc8-sf-web2.sourceforge.net>

Bugs item #676926, was opened at 2003-01-29 12:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676926&group_id=10127

Category: None
Group: Not a Bug
Status: Open
Resolution: Rejected
Priority: 3
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: memory leak in xmlparse.c::doProlog()

Initial Comment:
As of now, 2003/1/29, there is a memory leak in
xmlparse.c::doProlog() line 3979.

The XML_Content is dynamically allocated, but never
freed in the block.  The lifetime of the variable
content is not clear.  It is passed to
elementDeclHandler().  Does content need to be dynamic,
or can it be a local (stack) variable?  Does
elementDeclHandler() take ownership of content?

I can make the change in Python (which is where this
problem was found from test_minidom).

20 bytes in 1 blocks are definitely lost in loss record
2 of 15
  at 0x4015D480: malloc (vg_clientfuncs.c:100)
doProlog (python/dist/src/Modules/expat/xmlparse.c:3979)
prologProcessor
(python/dist/src/Modules/expat/xmlparse.c:3185)
prologInitProcessor
(python/dist/src/Modules/expat/xmlparse.c:3016)
XML_ParseBuffer
(python/dist/src/Modules/expat/xmlparse.c:1439)
XML_Parse (python/dist/src/Modules/expat/xmlparse.c:1427)
xmlparse_Parse (python/dist/src/Modules/pyexpat.c:853)


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-29 14:07

Message:
Logged In: YES 
user_id=3066

Sheesh, that'll teach me to read a report too quickly!  Dang 
crazy day job...

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-29 14:03

Message:
Logged In: YES 
user_id=290026

The content model needs to be freed by the application,
which is documented in reference.html.

We added a new API call in the current release,
XML_FreeContentModel, to make it easier for
non-C languages to free the content model
passed to the elemenDeclHandler.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-29 13:59

Message:
Logged In: YES 
user_id=3066

Oops, didn't mean to set the priority *that* high; it's a leak, 
not a segfault!

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

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

From noreply at sourceforge.net  Wed Jan 29 11:10:19 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jan 29 14:05:34 2003
Subject: [Expat-bugs] [ expat-Bugs-676926 ] memory leak in
	xmlparse.c::doProlog()
Message-ID: <E18dxbH-00004q-00@sc8-sf-web1.sourceforge.net>

Bugs item #676926, was opened at 2003-01-29 12:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676926&group_id=10127

Category: None
Group: Not a Bug
>Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: memory leak in xmlparse.c::doProlog()

Initial Comment:
As of now, 2003/1/29, there is a memory leak in
xmlparse.c::doProlog() line 3979.

The XML_Content is dynamically allocated, but never
freed in the block.  The lifetime of the variable
content is not clear.  It is passed to
elementDeclHandler().  Does content need to be dynamic,
or can it be a local (stack) variable?  Does
elementDeclHandler() take ownership of content?

I can make the change in Python (which is where this
problem was found from test_minidom).

20 bytes in 1 blocks are definitely lost in loss record
2 of 15
  at 0x4015D480: malloc (vg_clientfuncs.c:100)
doProlog (python/dist/src/Modules/expat/xmlparse.c:3979)
prologProcessor
(python/dist/src/Modules/expat/xmlparse.c:3185)
prologInitProcessor
(python/dist/src/Modules/expat/xmlparse.c:3016)
XML_ParseBuffer
(python/dist/src/Modules/expat/xmlparse.c:1439)
XML_Parse (python/dist/src/Modules/expat/xmlparse.c:1427)
xmlparse_Parse (python/dist/src/Modules/pyexpat.c:853)


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-29 14:07

Message:
Logged In: YES 
user_id=3066

Sheesh, that'll teach me to read a report too quickly!  Dang 
crazy day job...

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-29 14:03

Message:
Logged In: YES 
user_id=290026

The content model needs to be freed by the application,
which is documented in reference.html.

We added a new API call in the current release,
XML_FreeContentModel, to make it easier for
non-C languages to free the content model
passed to the elemenDeclHandler.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-29 13:59

Message:
Logged In: YES 
user_id=3066

Oops, didn't mean to set the priority *that* high; it's a leak, 
not a segfault!

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

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

From noreply at sourceforge.net  Wed Jan 29 13:26:15 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jan 29 16:21:38 2003
Subject: [Expat-bugs] [ expat-Bugs-569461 ] 1.95.3 and new OASIS xml test
	suite
Message-ID: <E18dzip-00081v-00@sc8-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: Accepted
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: 2003-01-29 16:26

Message:
Logged In: YES 
user_id=290026

This is just to report that the new release Expat 1.95.6
passes the OASIS test suite (same version - 20020606)
with the exact same results as Expat 1.95.5.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-21 14:21

Message:
Logged In: YES 
user_id=290026

For comparison purposes, I ran the xmltest.sh test script
against release 1.95.5. The results are attached as
TestResults_1_95_5.txt.

Discussion of results:

There are many cases were "output differs"is reported,
but these are due to xmlwf having a different definition
of "canonical XML" than used in the test suite.

Leaving these out, and those that were discussed 
already in this thread, we have the following errors 
reported:
(Note: the two test cases 
          ibm/not-wf/P32/ibm32n09.xml and
          ibm/not-wf/P68/ibm68n06.xml
          are not reported anymore by the script)

* In ibm/invalid/P49/: ibm49i02.xml:7:1: error in 
   processing external entity reference:
   The associated DTD file does not exist - an error
   in the test suite.

The next three documents are not UTF-8 encoded,
and do not have an XML declaration, so Expat rejects 
them, which is correct. An error in the test suite.

* In xmltest/valid/sa/: 049.xml:2:0: not well-formed 
   (invalid token)
* In xmltest/valid/sa/: 050.xml:2:0: not well-formed 
   (invalid token)
* In xmltest/valid/sa/: 051.xml:2:0: not well-formed 
   (invalid token)

The next two documents are classified as invalid,
but well-formed, but they contain faulty UTF-16 
encoding, so they should be classified as not
well-formed. Expat seems correct here.

* In sun/invalid/: utf16b.xml:2:0: not well-formed 
   (invalid token)
* In sun/invalid/: utf16l.xml:1:40: not well-formed 
   (invalid token)

The next three are not marked as why they should fail, 
so the script thinks they are not well-formed, but in
fact they are:

* Well formed: oasis/p06fail1.xml
* Well formed: oasis/p08fail1.xml
* Well formed: oasis/p08fail2.xml

So, no new test case errors have really been added
for release 1.95.5.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-19 14:01

Message:
Logged In: YES 
user_id=290026

Just a comment:
This bug report will likely stay open until Expat passes the
OASIS test suite without any problem at all.
Since no parser currently achieves this, there is a good
chance this bug report will stay open for a long time to come..


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

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 at sourceforge.net  Fri Jan 31 02:34:17 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan 31 05:29:22 2003
Subject: [Expat-bugs] 
	[ expat-Bugs-676844 ] expat.h compile error: enum XML_Status
Message-ID: <E18eYUz-0007pI-00@sc8-sf-web2.sourceforge.net>

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

Category: Build control
Group: None
Status: Open
Resolution: Fixed
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: expat.h compile error: enum XML_Status

Initial Comment:
c++ -DHAVE_CONFIG_H -I. -I. -I../../autocfg -g -O2 -c
context.cpp  -fPIC -DPIC -o .libs/context.lo
In file included from parser.h:45,
                 from guard.h:143,
                 from context.cpp:45:
/usr/include/expat.h:657: use of enum `XML_Status'
without previous declaration
/usr/include/expat.h:736: multiple definition of `enum
XML_Status'


when building sablotron.

Hand editing the file to place the def of enum
XML_Status before any references to it fixes the problem.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2003-01-31 02:34

Message:
Logged In: NO 

I just got the same error, already fixed it. But don't 
understand why it isn't fixed in CVS ?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-29 10:44

Message:
Logged In: YES 
user_id=3066

I've not checked the C89 standard yet, but Expat 1.95.6 is 
certainly dodgy in this case.  ;-(  The first draft of the C spec I 
found online certainly seemed to imply that any use of an 
incomplete enum is not allowed; I'm not likely to go out and 
buy a copy of the final spec to check further.  ;-)

As noted, this has been fixed in CVS.  Fixed the summary to 
better indicate what this report is about, and lowered the 
priority to get it out of the way for maintainers.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-29 07:51

Message:
Logged In: YES 
user_id=290026

So far only gcc3.2 has complained.
Not sure if this is a bug, since most compilers accept it,
but it has been fixed in CVS already anyway.

Set resolution status to fixed, but leave open.
There may be other users who would report this as a bug
and I want them to see the open report instead of 
having duplicates created.

Assigned to Fred - since he may know more about
whether this truly is a bug.

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

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

From noreply at sourceforge.net  Fri Jan 31 06:43:16 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jan 31 09:38:24 2003
Subject: [Expat-bugs] 
	[ expat-Bugs-676844 ] expat.h compile error: enum XML_Status
Message-ID: <E18ecNw-0000UM-00@sc8-sf-web2.sourceforge.net>

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

Category: Build control
Group: None
Status: Open
Resolution: Fixed
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: expat.h compile error: enum XML_Status

Initial Comment:
c++ -DHAVE_CONFIG_H -I. -I. -I../../autocfg -g -O2 -c
context.cpp  -fPIC -DPIC -o .libs/context.lo
In file included from parser.h:45,
                 from guard.h:143,
                 from context.cpp:45:
/usr/include/expat.h:657: use of enum `XML_Status'
without previous declaration
/usr/include/expat.h:736: multiple definition of `enum
XML_Status'


when building sablotron.

Hand editing the file to place the def of enum
XML_Status before any references to it fixes the problem.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-31 09:43

Message:
Logged In: YES 
user_id=290026

It *is* fixed in CVS. Are you sure you checked out the 
right version, which is expat.h 1.51?

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

Comment By: Nobody/Anonymous (nobody)
Date: 2003-01-31 05:34

Message:
Logged In: NO 

I just got the same error, already fixed it. But don't 
understand why it isn't fixed in CVS ?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-29 13:44

Message:
Logged In: YES 
user_id=3066

I've not checked the C89 standard yet, but Expat 1.95.6 is 
certainly dodgy in this case.  ;-(  The first draft of the C spec I 
found online certainly seemed to imply that any use of an 
incomplete enum is not allowed; I'm not likely to go out and 
buy a copy of the final spec to check further.  ;-)

As noted, this has been fixed in CVS.  Fixed the summary to 
better indicate what this report is about, and lowered the 
priority to get it out of the way for maintainers.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-29 10:51

Message:
Logged In: YES 
user_id=290026

So far only gcc3.2 has complained.
Not sure if this is a bug, since most compilers accept it,
but it has been fixed in CVS already anyway.

Set resolution status to fixed, but leave open.
There may be other users who would report this as a bug
and I want them to see the open report instead of 
having duplicates created.

Assigned to Fred - since he may know more about
whether this truly is a bug.

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

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