From noreply@sourceforge.net Sun Aug 4 18:48:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun Aug 4 17:48:02 2002 Subject: [ expat-Bugs-587211 ] make error Message-ID: Bugs item #587211, was opened at 2002-07-26 15:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=587211&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: make error Initial Comment: seaport:/tmp/expat-1.95.4# make /usr/bin/bash ./libtool --silent --mode=link gcc -g -O2 - Wall -Wmissing-prototypes -Wstrict-prototypes -I./lib - I. -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/unixfilemap.o libexpat.la xmlwf/xmlfile.o: Undefined symbol `_open' referenced (use -lc ?) xmlwf/xmlfile.o: Undefined symbol `_close' referenced (use -lc ?) xmlwf/xmlfile.o: Undefined symbol `_read' referenced (use -lc ?) xmlwf/unixfilemap.o: Undefined symbol `_open' referenced (use -lc ?) xmlwf/unixfilemap.o: Undefined symbol `_fstat' referenced (use -lc ?) xmlwf/unixfilemap.o: Undefined symbol `_close' referenced (use -lc ?) xmlwf/unixfilemap.o: Undefined symbol `_munmap' referenced (use -lc ?) ld: Spurious undefined symbols: # undefined symbols 5, reported 0 *** Error code 1 Stop. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-04 20:47 Message: Logged In: YES user_id=33168 If you add -lc to the link line between xmlwf/unixfilemap.o & libexpat.la, does it work? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-07-26 16:49 Message: Logged In: YES user_id=290026 Fred, maybe you can help. ---------------------------------------------------------------------- Comment By: Dave Reinhardt (thepair) Date: 2002-07-26 16:43 Message: Logged In: YES user_id=53868 seaport:/tmp/expat-1.95.0# which gcc /nfs/usr/bin/gcc seaport:/tmp/expat-1.95.0# gcc -v gcc version 2.7.2.1 ---------------------------------------------------------------------- Comment By: Dave Reinhardt (thepair) Date: 2002-07-26 16:40 Message: Logged In: YES user_id=53868 What OS/platform? Which version of it? PowerBSD Virtual Operating System v2.1 ELF-RELEASE (216.94.9.250) (ttyp0) PowerBSD v2.0-BETA - Copyright (c) 1997, 1998 Innosolve Systems Inc. What compiler version? can you tell from the output of the ./config command? loading cache ./config.cache checking host system type... i386-unknown-freebsd3.0 checking build system type... i386-unknown-freebsd3.0 checking for ranlib... (cached) ranlib checking for gcc... (cached) gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross- compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for ld used by GCC... (cached) /usr/libexec/aout/ld checking if the linker (/usr/libexec/aout/ld) is GNU ld... (cached) no checking for BSD-compatible nm... (cached) /nfs/usr/bin/nm - p checking whether ln -s works... (cached) yes updating cache ./config.cache loading cache ./config.cache within ltconfig checking for object suffix... o checking for executable suffix... (cached) no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.lo... yes checking if gcc supports -fno-rtti -fno-exceptions ... no checking if gcc static flag -static works... -static checking if the linker (/usr/libexec/aout/ld) is GNU ld... no checking whether the linker (/usr/libexec/aout/ld) supports shared libraries... yes checking command to parse /nfs/usr/bin/nm -p output... ok checking how to hardcode library paths into programs... immediate checking for /usr/libexec/aout/ld option to reload object files... -r checking dynamic linker characteristics... freebsd3.0 ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for objdir... .libs creating libtool updating cache ./config.cache loading cache ./config.cache checking for gcc... (cached) gcc checking whether the C compiler (gcc -g -O2 ) works... yes checking whether the C compiler (gcc -g -O2 ) is a cross- compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for a BSD compatible install... (cached) /nfs/usr/bin/install -c checking how to run the C preprocessor... (cached) gcc -E checking for ANSI C header files... (cached) yes checking for fcntl.h... (cached) yes checking for unistd.h... (cached) yes checking whether byte ordering is bigendian... (cached) no checking for working const... (cached) yes checking for off_t... (cached) yes checking for size_t... (cached) yes checking for 8-bit clean memcmp... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... (cached) yes checking for working mmap... (cached) yes checking for memmove... (cached) yes checking for bcopy... (cached) yes updating cache ./config.cache creating ./config.status creating Makefile creating lib/Makefile creating xmlwf/Makefile creating examples/Makefile creating config.h config.h is unchanged make cd lib; make /bin/sh ../libtool --mode=link gcc -version-info 0:0:0 -g -O2 -o libexpat.la -rpath /usr/local/lib xmlparse.lo xmltok.lo xmlrole.lo rm -fr .libs/libexpat.la .libs/libexpat.* .libs/libexpat.* (cd . && ln -s xmlparse.lo xmlparse.o) *** Error code 1 Stop. *** Error code 1 What configuration - any changes or default? default This is not assumed to be a bug. It is something about the way I am doing it or the fact that I do not have root access to the server. Only root to my virtual server. I have successfully installed others. etc., etc. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-07-26 16:07 Message: Logged In: YES user_id=290026 Everything we need to know to be able to reproduce your problem. Obviously it works for us, so where should we start? What OS/platform? Which version of it? What compiler version? What configuration - any changes or default? etc., etc. ---------------------------------------------------------------------- Comment By: Dave Reinhardt (thepair) Date: 2002-07-26 15:59 Message: Logged In: YES user_id=53868 what kind of additional info please ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-07-26 15:52 Message: Logged In: YES user_id=290026 Without more information we will need to close this report without action. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=587211&group_id=10127 From noreply@sourceforge.net Tue Aug 6 08:05:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Aug 6 07:05:05 2002 Subject: [ expat-Bugs-591556 ] Solaris make error Message-ID: Bugs item #591556, was opened at 2002-08-06 07:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=591556&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=591556&group_id=10127 From noreply@sourceforge.net Thu Aug 8 13:31:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Aug 8 12:31:01 2002 Subject: [ expat-Bugs-585537 ] XML_DefaultCurrent() not documented Message-ID: Bugs item #585537, was opened at 2002-07-23 14:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585537&group_id=10127 Category: Documentation Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: XML_DefaultCurrent() not documented Initial Comment: The XML_DefaultCurrent() function is not documented. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-08 15:30 Message: Logged In: YES user_id=3066 Fixed in doc/reference.html 1.16. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-07-25 19:47 Message: Logged In: YES user_id=290026 I would like to add here: The documentation for the default handler should be improved too, to be in sync with the comments in expat.h. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=585537&group_id=10127 From noreply@sourceforge.net Thu Aug 8 16:19:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Aug 8 15:19:04 2002 Subject: [ expat-Bugs-584041 ] Document handling of XML version Message-ID: Bugs item #584041, was opened at 2002-07-19 17:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584041&group_id=10127 >Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Håkan Waara (hwaara) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Document handling of XML version Initial Comment: In the XML spec it says that the parser may throw a parser error if the version is not "1.0" in the XML declaration. This is also what IE6 does. Here's a patch for this. It was diffed against mozilla.org's expat version, but I hope it can still be applied. Thanks, -Håkan ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-08 18:18 Message: Logged In: YES user_id=3066 Added information about this in doc/reference.html 1.19, including how an application can signal an error if an unsupported XML version is reported. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-07-22 13:02 Message: Logged In: YES user_id=290026 Fred, I wouldn't say you are a nobody ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-22 12:42 Message: Logged In: YES user_id=3066 Assigned to me and updated summary to reflect newfound existence as a request for documentation. Re-filed into the "bug" tracker. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-07-22 12:29 Message: Logged In: YES user_id=290026 I like the idea of leaving it to the application to make the call: error or not. Given the other arguments (mine included ) I reverse my vote - I am now in favour of the status quo. We will see what the experiences with the Mozilla version of Expat (where this patch comes from) will be ... Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-22 11:57 Message: Logged In: YES user_id=3066 While I like being really picky about checking input, I think there's a backward compatibility issue here. To turn version != "1.0" into an error, we break with expectations established by previous releases. Expat legacy does not turn conditions into actual errors if it isn't necessary, so "may" raise an error is not strong enough to go against existing behavior. If a particular application is interested in deteriming what XML version was given, it may do so using XML_SetXmlDeclHandler(), raising any sort of error appropriate at that point. This should be documented (assign to me for docs once we reach agreement). XML 1.1 feels sufficiently rough at this point that we don't need to implement to it. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-07-22 09:43 Message: Logged In: YES user_id=290026 One caveat though: What will happen with XML 1.1 documents that also conform to XML 1.0? Should the parser reject them? That might potentially exclude many "good" documents. Maybe an option should be added to turn version number errors of. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-07-20 21:58 Message: Logged In: YES user_id=290026 The patch didn't work for me, but I applied it manually against my copy of the current CVS (xmltok.c 1.20) - with small cosmetic changes. Attached as xmltok.diff. I am in favour of it. Let's see what the others say. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-07-20 11:59 Message: Logged In: YES user_id=290026 Yes, I have read the spec too. I also read about the XML 1.1 spec making it a requirement. I am just putting it up for discussion. Why don't you post to the expat-discuss list? Karl ---------------------------------------------------------------------- Comment By: Håkan Waara (hwaara) Date: 2002-07-20 11:51 Message: Logged In: YES user_id=72743 From noreply@sourceforge.net Wed Aug 14 02:54:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Aug 14 01:54:04 2002 Subject: [ expat-Bugs-594963 ] segmentation fault in function hash Message-ID: Bugs item #594963, was opened at 2002-08-14 01:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=594963&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault in function hash Initial Comment: expat 1.95.4 crashed in function lookup -> hash when used in my program. When used as parseXml -ivt **.T34 outx a memory error follows and a crash. This does not happend when line is removed or T34 is changed to T35 or an other item. GDB tells me it is a segmentation error. OS is HPUX-11. Compiler is GCC, Lang is ANSI-C. Can be circumvented by setting INIT_SIZE to 128 in xmlparse.c but no guaranties. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=594963&group_id=10127 From noreply@sourceforge.net Wed Aug 14 07:05:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Aug 14 06:05:04 2002 Subject: [ expat-Bugs-594963 ] segmentation fault in function hash Message-ID: Bugs item #594963, was opened at 2002-08-14 04:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=594963&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault in function hash Initial Comment: expat 1.95.4 crashed in function lookup -> hash when used in my program. When used as parseXml -ivt **.T34 outx a memory error follows and a crash. This does not happend when line is removed or T34 is changed to T35 or an other item. GDB tells me it is a segmentation error. OS is HPUX-11. Compiler is GCC, Lang is ANSI-C. Can be circumvented by setting INIT_SIZE to 128 in xmlparse.c but no guaranties. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-14 09:04 Message: Logged In: YES user_id=290026 Roel Dijkema was not able to upload the bug demo. I did that for him. Comment: It would be much appreciated if the demo could be reduced to the bare minimum that still shows the bug. Otherwise it may take too long to isolate the problem - since we all would like to use our limited volunteer time efficiently. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=594963&group_id=10127 From noreply@sourceforge.net Thu Aug 15 08:26:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Aug 15 07:26:02 2002 Subject: [ expat-Bugs-595532 ] xmlwf -x not reading the external DTD Message-ID: Bugs item #595532, was opened at 2002-08-15 16:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=595532&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michel Rodriguez (mirod) Assigned to: Nobody/Anonymous (nobody) Summary: xmlwf -x not reading the external DTD Initial Comment: xmlwf test_ext_ent.xml gives me an error on an undefined entity despite it being defined in the (external) DTD >xmlwf -x test_ext_ent.xml test_ext_ent.xml:2:5: undefined entity --- test_ext_ent.xml --- &ent; --- test_ext_ent.dtd --- It has no problem if I do xmlwf -p test_ext_ent.xml Shouldn't -x find the entity declaration in the DTD? That's with expat 1.95.4 -- Michel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=595532&group_id=10127 From noreply@sourceforge.net Thu Aug 15 09:15:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Aug 15 08:15:03 2002 Subject: [ expat-Bugs-595532 ] xmlwf -x not reading the external DTD Message-ID: Bugs item #595532, was opened at 2002-08-15 10:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=595532&group_id=10127 Category: None Group: None Status: Open >Resolution: Rejected Priority: 5 Submitted By: Michel Rodriguez (mirod) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xmlwf -x not reading the external DTD Initial Comment: xmlwf test_ext_ent.xml gives me an error on an undefined entity despite it being defined in the (external) DTD >xmlwf -x test_ext_ent.xml test_ext_ent.xml:2:5: undefined entity --- test_ext_ent.xml --- &ent; --- test_ext_ent.dtd --- It has no problem if I do xmlwf -p test_ext_ent.xml Shouldn't -x find the entity declaration in the DTD? That's with expat 1.95.4 -- Michel ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-15 11:14 Message: Logged In: YES user_id=290026 I am not the expert on xmlwf, but by looking at the code, it appears that parameter entity parsing is turned off when -p is not specified. Since Expat considers an external DTD a parameter entity - check reference.html - it will consequently not read it. Therefore the entity declaration for &ent; will be missing. Btw, -p implies -x, AFAIK. This is not a bug, as far as I can tell, but I leave it open for Fred to comment. Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=595532&group_id=10127 From noreply@sourceforge.net Thu Aug 15 23:25:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Aug 15 22:25:02 2002 Subject: [ expat-Bugs-595532 ] xmlwf -x not reading the external DTD Message-ID: Bugs item #595532, was opened at 2002-08-15 16:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=595532&group_id=10127 Category: None Group: None Status: Open Resolution: Rejected Priority: 5 Submitted By: Michel Rodriguez (mirod) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xmlwf -x not reading the external DTD Initial Comment: xmlwf test_ext_ent.xml gives me an error on an undefined entity despite it being defined in the (external) DTD >xmlwf -x test_ext_ent.xml test_ext_ent.xml:2:5: undefined entity --- test_ext_ent.xml --- &ent; --- test_ext_ent.dtd --- It has no problem if I do xmlwf -p test_ext_ent.xml Shouldn't -x find the entity declaration in the DTD? That's with expat 1.95.4 -- Michel ---------------------------------------------------------------------- >Comment By: Michel Rodriguez (mirod) Date: 2002-08-16 07:24 Message: Logged In: YES user_id=72556 Don't you think that using xmlwf with no options on a well-formed xml file should not return an error, even if the file is not standalone? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-15 17:14 Message: Logged In: YES user_id=290026 I am not the expert on xmlwf, but by looking at the code, it appears that parameter entity parsing is turned off when -p is not specified. Since Expat considers an external DTD a parameter entity - check reference.html - it will consequently not read it. Therefore the entity declaration for &ent; will be missing. Btw, -p implies -x, AFAIK. This is not a bug, as far as I can tell, but I leave it open for Fred to comment. Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=595532&group_id=10127 From noreply@sourceforge.net Fri Aug 16 07:21:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Aug 16 06:21:02 2002 Subject: [ expat-Bugs-595532 ] xmlwf -x not reading the external DTD Message-ID: Bugs item #595532, was opened at 2002-08-15 10:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=595532&group_id=10127 Category: None Group: None Status: Open Resolution: Rejected Priority: 5 Submitted By: Michel Rodriguez (mirod) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xmlwf -x not reading the external DTD Initial Comment: xmlwf test_ext_ent.xml gives me an error on an undefined entity despite it being defined in the (external) DTD >xmlwf -x test_ext_ent.xml test_ext_ent.xml:2:5: undefined entity --- test_ext_ent.xml --- &ent; --- test_ext_ent.dtd --- It has no problem if I do xmlwf -p test_ext_ent.xml Shouldn't -x find the entity declaration in the DTD? That's with expat 1.95.4 -- Michel ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-16 09:20 Message: Logged In: YES user_id=290026 Maybe, but that is a matter of specifications, not a bug. Consider this: external entity references can be anything, not just references to files. You could have an URL, or some Public Id for instance. But xmlwf only provides external entity reference resolution for files. From noreply@sourceforge.net Fri Aug 16 08:26:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Aug 16 07:26:04 2002 Subject: [ expat-Bugs-596059 ] Parser !initialized when XML_DTD undef Message-ID: Bugs item #596059, was opened at 2002-08-16 07:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596059&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Parser !initialized when XML_DTD undef Initial Comment: The parser does not seem to be properly initialized if XML_DTD is not defined. The dtdInit functions is only called if XML_DTD is defined, but dtdInit itself has internal #ifdef XML_DTD which seems to indicate it should be called with or without XML_DTD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596059&group_id=10127 From noreply@sourceforge.net Fri Aug 16 08:33:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Aug 16 07:33:02 2002 Subject: [ expat-Bugs-596059 ] Parser !initialized when XML_DTD undef Message-ID: Bugs item #596059, was opened at 2002-08-16 10:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596059&group_id=10127 Category: None Group: None Status: Open >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Karl Waclawek (kwaclaw) Summary: Parser !initialized when XML_DTD undef Initial Comment: The parser does not seem to be properly initialized if XML_DTD is not defined. The dtdInit functions is only called if XML_DTD is defined, but dtdInit itself has internal #ifdef XML_DTD which seems to indicate it should be called with or without XML_DTD. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-16 10:32 Message: Logged In: YES user_id=290026 This seems to be a duplicate of bug # 584183 which has been fixed in CVS. Please check out the latest revision from CVS and report if that resolves it for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596059&group_id=10127 From noreply@sourceforge.net Fri Aug 16 08:44:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Aug 16 07:44:04 2002 Subject: [ expat-Bugs-594963 ] segmentation fault in function hash Message-ID: Bugs item #594963, was opened at 2002-08-14 04:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=594963&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: segmentation fault in function hash Initial Comment: expat 1.95.4 crashed in function lookup -> hash when used in my program. When used as parseXml -ivt **.T34 outx a memory error follows and a crash. This does not happend when line is removed or T34 is changed to T35 or an other item. GDB tells me it is a segmentation error. OS is HPUX-11. Compiler is GCC, Lang is ANSI-C. Can be circumvented by setting INIT_SIZE to 128 in xmlparse.c but no guaranties. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-16 10:43 Message: Logged In: YES user_id=290026 Assigned to Fred. Hope he has time to give it a quick check. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-14 09:04 Message: Logged In: YES user_id=290026 Roel Dijkema was not able to upload the bug demo. I did that for him. Comment: It would be much appreciated if the demo could be reduced to the bare minimum that still shows the bug. Otherwise it may take too long to isolate the problem - since we all would like to use our limited volunteer time efficiently. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=594963&group_id=10127 From noreply@sourceforge.net Sat Aug 17 14:32:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Aug 17 13:32:01 2002 Subject: [ expat-Bugs-596555 ] rephrase "xml p.i." message Message-ID: Bugs item #596555, was opened at 2002-08-17 13:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596555&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: rephrase "xml p.i." message Initial Comment: expat.c contains this message: XML_L("xml processing instruction not at start of external entity"), but "xml processing instruction" is a misnomer. Although this message appears when a processing instruction with the illegal target "xml" is encountered, the error message should not imply that the structure that belongs at the start of an external entity is a processing instruction. I suggest changing this phrase to the more correct "XML or text declaration not at start of external entity" so as not to perpetuate common misconceptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596555&group_id=10127 From noreply@sourceforge.net Sat Aug 17 22:20:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Aug 17 21:20:02 2002 Subject: [ expat-Bugs-596678 ] XML_ParserReset not documented Message-ID: Bugs item #596678, was opened at 2002-08-18 00:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596678&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: XML_ParserReset not documented Initial Comment: Reference.html contains no reference to XML_ParserReset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596678&group_id=10127 From noreply@sourceforge.net Sun Aug 18 18:26:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun Aug 18 17:26:01 2002 Subject: [ expat-Bugs-596931 ] XML_ParseReset and memory leaks Message-ID: Bugs item #596931, was opened at 2002-08-18 17:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596931&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XML_ParseReset and memory leaks Initial Comment: The problem: XML_ParseReset function does not reset the parser correctly, resulting in memory leaks. These leaks can be observed using the windows task manager while running the sample code below. Expat version: 1.95.4 Platform: win200 Sample Application: include #include "expat.h" char buffer[] = ""; void main() { XML_Parser parser = XML_ParserCreate(NULL); while ( true ) { int ret = XML_Parse( parser, buffer, strlen(buffer ), 1); if( ret == 0 ) { abort(); } ret = XML_ParserReset( parser, NULL ); if( ret == 0 ) { abort(); } } } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596931&group_id=10127 From noreply@sourceforge.net Sun Aug 18 19:54:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun Aug 18 18:54:02 2002 Subject: [ expat-Bugs-596931 ] XML_ParseReset and memory leaks Message-ID: Bugs item #596931, was opened at 2002-08-18 20:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596931&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Karl Waclawek (kwaclaw) Summary: XML_ParseReset and memory leaks Initial Comment: The problem: XML_ParseReset function does not reset the parser correctly, resulting in memory leaks. These leaks can be observed using the windows task manager while running the sample code below. Expat version: 1.95.4 Platform: win200 Sample Application: include #include "expat.h" char buffer[] = ""; void main() { XML_Parser parser = XML_ParserCreate(NULL); while ( true ) { int ret = XML_Parse( parser, buffer, strlen(buffer ), 1); if( ret == 0 ) { abort(); } ret = XML_ParserReset( parser, NULL ); if( ret == 0 ) { abort(); } } } ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-18 21:53 Message: Logged In: YES user_id=290026 Yes, this is a bug, as discussed on expat-discuss. I have attached a first patch - still to be tested. The problem was that dtdDestroy was not called in XML_ParserReset, since dtd.scaffold was NULL. Then, when dtdInit() was later called in parserInit, the pointers were overwritten - leading to memory leaks. This was a logic problem - the original reason for checking dtd.scaffold was to prevent double-destroying the dtd structure, but dtd.scaffold was only set when there was a content model. I changed this by introducing the new functions dtdReset() and hashTableClear(). There were other logic errors too, that would not show up in the test case given, but would have led to memory leaks in other situations: - freeBindingList and inheritedBindings were overwritten - tagStack and freeTagList were overwritten - groupSize and groupConnector were overwritten Other changes: - There is no reason to have dtdDestroy/dtdReset conditional on XML_DTD. - The unknownEncodingHandler(Data) is not reset anymore, since this is not really a dynamic handler anyway. - I also removed dtdInit() from parserInit() and it is now called separately. - The return type of XML_ParserReset was changed from int to XML_Bool. This should not be much of a problem, since it is binary compatible, and XML_ParserReset is new and not even documented yet. - A couple of minor code cleanups were performed too, not to confuse the reader. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596931&group_id=10127 From noreply@sourceforge.net Tue Aug 20 12:19:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Aug 20 11:19:05 2002 Subject: [ expat-Bugs-597878 ] expat-1.95.4 . Warning during make Message-ID: Bugs item #597878, was opened at 2002-08-20 11:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=597878&group_id=10127 Category: www.libexpat.org Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat-1.95.4 . Warning during make Initial Comment: Hi, during make for expat1-95.4 . I am getting this warning mesage (libtool: link: warning: this platform does not like uninstalled shared libraries") Is this Normal ? I am trying to install it in HP UX 11.0(64 Bit ) with perl5.6.1 . I need to build XML Parser on top of this . boi48@/tmp/sanjay/XMLP/expat-1.95.4% ./configure checking build system type... hppa2.0w-hp-hpux11.00 checking host system type... hppa2.0w-hp-hpux11.00 checking for gcc... no checking for cc... cc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether cc accepts -g... yes checking for non-GNU ld... /bin/ld checking if the linker (/bin/ld) is GNU ld... no checking for /bin/ld option to reload object files... -r checking for BSD-compatible nm... /bin/nm -p checking whether ln -s works... yes checking how to recognise dependant libraries... file_magic (s[0-9][0-9][0-9]|PA-RISC[0-9].[0-9]) shared library checking command to parse /bin/nm -p output... ok checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for cc option to produce PIC... +Z checking if cc PIC flag +Z works... yes checking if cc static flag -Wl,-a -Wl,archive works... yes checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.lo... yes checking whether the linker (/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... relink checking whether stripping libraries is possible... no checking dynamic linker characteristics... hpux11.00 dld.sl checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes creating libtool checking for gcc... (cached) cc checking whether we are using the GNU C compiler... (cached) no checking whether cc accepts -g... (cached) yes checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking whether byte ordering is bigendian... yes checking for cc option to accept ANSI C... none needed checking for an ANSI C-conforming const... yes checking for off_t... yes checking for size_t... yes checking for working memcmp... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... no checking for memmove... yes checking for bcopy... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h boi48@/tmp/sanjay/XMLP/expat-1.95.4% make /bin/sh ./libtool --silent --mode=compile cc -g - I./lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile cc -g - I./lib -I. -o lib/xmltok.lo -c lib/xmltok.c /bin/sh ./libtool --silent --mode=compile cc -g - I./lib -I. -o lib/xmlrole.lo -c lib/xmlrole.c /bin/sh ./libtool --silent --mode=link cc -g -I./lib -I. - no-undefined -version-info 3:0:3 -rpath /usr/local/lib -o libeo cc -g -I./lib -I. -o xmlwf/xmlwf.o -c xmlwf/xmlwf.c cc -g -I./lib -I. -o xmlwf/xmlfile.o -c xmlwf/xmlfile.c cc -g -I./lib -I. -o xmlwf/codepage.o -c xmlwf/codepage.c cc -g -I./lib -I. -o xmlwf/readfilemap.o -c xmlwf/readfilemap.c /bin/sh ./libtool --silent --mode=link cc -g -I./lib - I. -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xa libtool: link: warning: this platform does not like uninstalled shared libraries libtool: link: `xmlwf/xmlwf' will be relinked during installation ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=597878&group_id=10127 From noreply@sourceforge.net Tue Aug 20 12:44:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Aug 20 11:44:03 2002 Subject: [ expat-Bugs-597887 ] ld: Mismatched ABI (not an ELF file) for Message-ID: Bugs item #597887, was opened at 2002-08-20 11:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=597887&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ld: Mismatched ABI (not an ELF file) for Initial Comment: I installed expat1.95.4 . Now when i build the XML- PARSER2.31 . 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/xs 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=597887&group_id=10127 From noreply@sourceforge.net Wed Aug 21 10:50:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Aug 21 09:50:17 2002 Subject: [ expat-Patches-598352 ] Patch for defaultHandler in DTD Message-ID: Patches item #598352, was opened at 2002-08-21 12:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=598352&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Patch for defaultHandler in DTD Initial Comment: This patch fixes the problem of having the default handler called for DTD declarations, when a designated handler is already provided. Check bug #483514: "Default handler reports handled events". There is one limitation to this fix: When there is an entityDeclHandler set, then predefined and duplicate entity declarations will be reported only partially by the default handler. The reason is that at the time when it is detected that the entity is a predefined one, or that the declaration is a duplicate, part of the declaration has already been reported. Example: Instead of the default handler will only report quot""" For details see the attached overview. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=598352&group_id=10127 From elvie1020c61@domeus.co.uk Thu Aug 22 00:37:04 2002 From: elvie1020c61@domeus.co.uk (elvie1020c61@domeus.co.uk) Date: Wed Aug 21 23:37:04 2002 Subject: Get your college degree today! 7679VwcR2-644fw-14 Message-ID: <037e70c41d3e$1738d7e3$8aa25bc6@lorwsu> U N I V E R S I T Y D I P L O M A S Obtain a prosperous future, money, earning power, and the admiration of all! Diplomas from Prestigious non-accredited Universities based on your present knowledge and life experience. NO Required Tests, Classes, Books, or Interviews! Bachelors, Masters, MBA, and Doctorate (PHD) Diplomas available in the field of your choice. No one is turned down! Confidentiality assured. CALL NOW to receive your diploma within days!!! 1 - 7 7 3 - 5 0 9 - 6 4 4 5 Call 24 hours a day, 7 days a week, including Sundays and holidays. ****************** Opt-Out Instructions ****************** If you would like to terminate further emails such as this: Simply click the email link below to send us a removal request: mailto:nomoremail@excite.com?subject=RemoveMeDiplomas 4779HEHL4-833ZTbh9379afJr7-196ntGs9311Bbetl40 5331egwz2-201cSms2331WJgX4-383sytA7l33 From noreply@sourceforge.net Thu Aug 22 08:57:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Aug 22 07:57:02 2002 Subject: [ expat-Patches-598352 ] Patch for defaultHandler in DTD Message-ID: Patches item #598352, was opened at 2002-08-21 12:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=598352&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Patch for defaultHandler in DTD Initial Comment: This patch fixes the problem of having the default handler called for DTD declarations, when a designated handler is already provided. Check bug #483514: "Default handler reports handled events". There is one limitation to this fix: When there is an entityDeclHandler set, then predefined and duplicate entity declarations will be reported only partially by the default handler. The reason is that at the time when it is detected that the entity is a predefined one, or that the declaration is a duplicate, part of the declaration has already been reported. Example: Instead of the default handler will only report quot""" For details see the attached overview. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-22 10:56 Message: Logged In: YES user_id=290026 Passed my own tests as well as the W3C test suite, according to what we expect as a result. No change in behaviour from release 1.95.4. Therefore it seemed OK to apply the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=598352&group_id=10127 From noreply@sourceforge.net Thu Aug 22 09:09:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Aug 22 08:09:06 2002 Subject: [ expat-Bugs-596931 ] XML_ParseReset and memory leaks Message-ID: Bugs item #596931, was opened at 2002-08-18 20:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596931&group_id=10127 Category: None Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: XML_ParseReset and memory leaks Initial Comment: The problem: XML_ParseReset function does not reset the parser correctly, resulting in memory leaks. These leaks can be observed using the windows task manager while running the sample code below. Expat version: 1.95.4 Platform: win200 Sample Application: include #include "expat.h" char buffer[] = ""; void main() { XML_Parser parser = XML_ParserCreate(NULL); while ( true ) { int ret = XML_Parse( parser, buffer, strlen(buffer ), 1); if( ret == 0 ) { abort(); } ret = XML_ParserReset( parser, NULL ); if( ret == 0 ) { abort(); } } } ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-22 11:08 Message: Logged In: YES user_id=290026 Patch applied - seems OK since it passed all my tests as well as the W3C test suite (with results as expected, no change from release 1.95.4). Hopefully that will get more people to test it. It seems the user community at large will only really use and test full releases, and to a lesser degree CVS submissions. Leave it open for a while, since we may get some feedback. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-18 21:53 Message: Logged In: YES user_id=290026 Yes, this is a bug, as discussed on expat-discuss. I have attached a first patch - still to be tested. The problem was that dtdDestroy was not called in XML_ParserReset, since dtd.scaffold was NULL. Then, when dtdInit() was later called in parserInit, the pointers were overwritten - leading to memory leaks. This was a logic problem - the original reason for checking dtd.scaffold was to prevent double-destroying the dtd structure, but dtd.scaffold was only set when there was a content model. I changed this by introducing the new functions dtdReset() and hashTableClear(). There were other logic errors too, that would not show up in the test case given, but would have led to memory leaks in other situations: - freeBindingList and inheritedBindings were overwritten - tagStack and freeTagList were overwritten - groupSize and groupConnector were overwritten Other changes: - There is no reason to have dtdDestroy/dtdReset conditional on XML_DTD. - The unknownEncodingHandler(Data) is not reset anymore, since this is not really a dynamic handler anyway. - I also removed dtdInit() from parserInit() and it is now called separately. - The return type of XML_ParserReset was changed from int to XML_Bool. This should not be much of a problem, since it is binary compatible, and XML_ParserReset is new and not even documented yet. - A couple of minor code cleanups were performed too, not to confuse the reader. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596931&group_id=10127 From noreply@sourceforge.net Thu Aug 22 13:26:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Aug 22 12:26:02 2002 Subject: [ expat-Patches-598944 ] Static library builds for VC++ Message-ID: Patches item #598944, was opened at 2002-08-22 15:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=598944&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Static library builds for VC++ Initial Comment: I added projects for building static libraries to the MS VC++ project files. I also changed the "elements" demo project to use the static version of libexpat. Small changes had to be made to expat.h and xmlparse.c - check the patch included in the attached zip archive. Other minor changes were made with regards to have all projects link to the same version of the runtime library. Btw, using the static library forces an application to link to the same version of the runtime as Expat, or rebuild the library accordingly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=598944&group_id=10127 From noreply@sourceforge.net Fri Aug 23 09:08:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Aug 23 08:08:04 2002 Subject: [ expat-Patches-598944 ] Static library builds for VC++ Message-ID: Patches item #598944, was opened at 2002-08-22 15:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=598944&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Static library builds for VC++ Initial Comment: I added projects for building static libraries to the MS VC++ project files. I also changed the "elements" demo project to use the static version of libexpat. Small changes had to be made to expat.h and xmlparse.c - check the patch included in the attached zip archive. Other minor changes were made with regards to have all projects link to the same version of the runtime library. Btw, using the static library forces an application to link to the same version of the runtime as Expat, or rebuild the library accordingly. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-23 11:07 Message: Logged In: YES user_id=290026 Works for me - applied to CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=598944&group_id=10127 From fdrake@acm.org Fri Aug 23 13:22:25 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri Aug 23 12:22:25 2002 Subject: Expat mailing lists are moving Message-ID: <15718.35598.477399.965833@grendel.zope.com> All three of the mailing lists for the Expat project are moving, and will no longer be hosted at SourceForge. SourceForge has proven itself an incredibly valuable resource for open source developers, and it's certainly made the continued maintenance of Expat much nicer than it could have been. Unfortunaltey, it's very success has caused it enough load on their systems that the performance and reliability of some components has fallen behind, most importantly the mailing list servers. To avoid suffering the highly variable delays in getting mail off the SourceForge list servers to recipients' inboxes, we're going to host the lists in the libexpat.org domain. We will continue to use the Mailman mailing list manager used on SourceForge, but using the list archive software provided with Mailman, which isn't quite as nice as the archive interface available on SourceForge. The new lists have been created, and we'll probably shut down the old lists next week. You can subscribe to the new lists at: http://mail.libexpat.org/mailman-21/listinfo/ The mail from the revision control system and the issue trackers will be won't re-directed to the new lists until early next week, to give you time to subscribe to the new lists. Please let me know if you have any problems with these changes. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From noreply@sourceforge.net Fri Aug 23 18:05:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Aug 23 17:05:08 2002 Subject: [ expat-Bugs-599470 ] (1.95.4) runtests fails on MacOSX Message-ID: Bugs item #599470, was opened at 2002-08-24 00:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=599470&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Erwin (jerwin) Assigned to: Nobody/Anonymous (nobody) Summary: (1.95.4) runtests fails on MacOSX Initial Comment: I attempted to run "make check". However, the runtests script is erroneous labeled as a "sh" script. It runs properly under "bash". I'm running MacOSX 10.1. I'm not sure who's to blame for this-- the runtests script is listed as "generated by libtool". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=599470&group_id=10127 From noreply@sourceforge.net Sat Aug 24 12:36:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Aug 24 11:36:04 2002 Subject: [ expat-Patches-599715 ] Enable undeclared DTD Message-ID: Patches item #599715, was opened at 2002-08-24 14:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=599715&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Enable undeclared DTD Initial Comment: SAX2 provides the ability to use a customer provided external DTD when there is no external subset. Check out the definition of getExternalSubset on this page: http://sax.sourceforge.net/apidoc/org/xml/sax/ext/Entity Resolver2.html I patched Expat to enable such behaviour. When the user calls the new API function XML_UseForeignDTD() with an argument of XML_TRUE, then the externalEntityRefHandler will be called even if there is no external subset/DTD declared. In such a case the systemId argument will be NULL. A "foreign DTD" would be interpreted just as if the document had an external subset reference, that is, the internal field dtd.hasParamEntityRefs would become true. Patch attached. This patch also includes additional improvements/fixes that became apparent when working on the patch. These affect the function dtdReset() and the notStandaloneHandler(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=599715&group_id=10127 From noreply@sourceforge.net Sat Aug 24 17:29:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Aug 24 16:29:02 2002 Subject: [ expat-Patches-599715 ] Enable undeclared DTD Message-ID: Patches item #599715, was opened at 2002-08-24 14:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=599715&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Enable undeclared DTD Initial Comment: SAX2 provides the ability to use a customer provided external DTD when there is no external subset. Check out the definition of getExternalSubset on this page: http://sax.sourceforge.net/apidoc/org/xml/sax/ext/Entity Resolver2.html I patched Expat to enable such behaviour. When the user calls the new API function XML_UseForeignDTD() with an argument of XML_TRUE, then the externalEntityRefHandler will be called even if there is no external subset/DTD declared. In such a case the systemId argument will be NULL. A "foreign DTD" would be interpreted just as if the document had an external subset reference, that is, the internal field dtd.hasParamEntityRefs would become true. Patch attached. This patch also includes additional improvements/fixes that became apparent when working on the patch. These affect the function dtdReset() and the notStandaloneHandler(). ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-24 19:28 Message: Logged In: YES user_id=290026 Made small improvement to patch. Thinking about changing the API from XML_UseForeignDTD(parser, useDTD) to XML_SetUseForeignDTDHandler(parser, callback). The value of the internal field useForeignDTD is used only once, but updated multiple times. With the orginal API the caller has write access to this field and can potentially mess up the logic, with the new one, the parser reads it when it needs it, and then has full control. Comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=599715&group_id=10127 From noreply@sourceforge.net Sun Aug 25 14:29:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun Aug 25 13:29:02 2002 Subject: [ expat-Patches-599715 ] Enable undeclared DTD Message-ID: Patches item #599715, was opened at 2002-08-24 14:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=599715&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Enable undeclared DTD Initial Comment: SAX2 provides the ability to use a customer provided external DTD when there is no external subset. Check out the definition of getExternalSubset on this page: http://sax.sourceforge.net/apidoc/org/xml/sax/ext/Entity Resolver2.html I patched Expat to enable such behaviour. When the user calls the new API function XML_UseForeignDTD() with an argument of XML_TRUE, then the externalEntityRefHandler will be called even if there is no external subset/DTD declared. In such a case the systemId argument will be NULL. A "foreign DTD" would be interpreted just as if the document had an external subset reference, that is, the internal field dtd.hasParamEntityRefs would become true. Patch attached. This patch also includes additional improvements/fixes that became apparent when working on the patch. These affect the function dtdReset() and the notStandaloneHandler(). ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-25 16:28 Message: Logged In: YES user_id=290026 I added the macro #define parsing (processor != prologInitProcessor) which returns true once XML_Parse or XML_ParseBuffer has been called. This is used to block setting of the useForeignDTD flag when parsing is under way. I have also applied this logic to these other functions: XML_SetEncoding XML_SetParamEntityParsing XML_SetReturnNSTriplets Since there is a chance that parser logic might get upset if the corresponding flags are changed after parsing has begun. New patch version attached with description "Patch with safety feature added". ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-24 19:28 Message: Logged In: YES user_id=290026 Made small improvement to patch. Thinking about changing the API from XML_UseForeignDTD(parser, useDTD) to XML_SetUseForeignDTDHandler(parser, callback). The value of the internal field useForeignDTD is used only once, but updated multiple times. With the orginal API the caller has write access to this field and can potentially mess up the logic, with the new one, the parser reads it when it needs it, and then has full control. Comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=599715&group_id=10127 From 4124o03@cs.com Wed Aug 28 21:27:04 2002 From: 4124o03@cs.com (4124o03@cs.com) Date: Wed Aug 28 20:27:04 2002 Subject: Time to detox. Message-ID: <020c07a04c8b$1431d1b8$8bd62ce7@augjlu> ---------------------- multipart/mixed attachment RGVhciBBbHRlcm5hdGl2ZSBIZWFsdGggU3R1ZGVudCwNCg0KTGV0IG1lIGFz ayB5b3UgdGhpcy4uLndoaWNoIGlzIHdvcnNlOiAgIA0KDQpBLiBUaGUgZW5n aW5lIG9uIHlvdXIgTGV4dXMgZnJlZXplcyB1cCBhdCAxNjAsMDAwIG1pbGVz IGluc3RlYWQgDQpvZiAzMDAsMDAwLiBZb3UgdGFrZSBhIGZpbmFuY2lhbCBo aXQgYW5kIHlvdSBhcmUgZm9yY2VkIHRvIGJ1eSANCmEgVG95b3RhIHRoaXMg dGltZS4gDQoNCkIuIFlvdSBzdGFydCBibGVlZGluZyBkdXJpbmcgYm93ZWwg bW92ZW1lbnRzLiBZb3UgZ28gdG8gdGhlIGRvY3RvciANCmFuZCBnZXQgcG9r ZWQsIHByb2RkZWQsIFgtcmF5J2QsIGJpb3BzaWVkLCBldGMuIDMgZGF5cyBs YXRlciB5b3UgDQpnZXQgYSBjYWxsIGZvciBhIGNvbnN1bHRhdGlvbi4gVGhl IGRvY3RvciBpbmZvcm1zIHlvdSB0aGF0IHlvdSBoYXZlIA0KYWR2YW5jZWQg Y29sb24gY2FuY2VyIGF0IDQ1IHllYXJzIG9sZC4gWW91IGhhdmUgYW55d2hl cmUgZnJvbSA2IA0KbW9udGhzIHRvIDUgeWVhcnMgbGVmdCB0byBsaXZlLiBI ZSB0ZWxscyB5b3UgaXQncyB0aW1lIHRvIGdldCB5b3VyIA0KaG91c2UgaW4g b3JkZXIgYmVjYXVzZSB5b3UnbGwgYmUgY2hlY2tpbmcgb3V0IHNvb24uIENo ZW1vdGhlcmFweSANCnN0YXJ0cyB0b2RheS4gDQoNCkEgZnJpZW5kIG9mIGFu b3RoZXIgd3JpdGVyLCB3aG8gd2FzIGEgc2NpZW5jZSBhbmQgaGVhbHRoIHJl c2VhcmNoZXIgDQphdCB0aGUgVW5pdmVyc2l0eSBvZiBDaGljYWdvLCBqdXN0 IGRpZWQgdGhpcyBwYXN0IHllYXIgb2YgY29sb24gY2FuY2VyIA0KYXQgNDIu IEluIHRoZSBtaWRzdCBvZiB0aGUgcHJpbWUgb2YgaGlzIGxpZmUsIGhlIHNh aWQgZ29vZGJ5ZSwgYW5kIA0KbGVmdCBoaXMgd2lmZSBhbmQgY2hpbGQgYmVo aW5kLCB3b25kZXJpbmcgd2hhdCBqdXN0IGhpdCB0aGVtLiANCg0KV2h5IGRv IHlvdSBicnVzaCB5b3VyIHRlZXRoPyBBcmUgeW91ciB0ZWV0aCBmYWxsaW5n IG91dCByaWdodCBub3c/IEZvciANCm1vc3Qgb2YgdXMsIHdlIGRvIGl0IHNv IHdlIHdvbid0IG5lZWQgZmFsc2UgdGVldGggYW5kIEZpeG9kZW50IGRvd24g dGhlIA0Kcm9hZC4uLnJpZ2h0PyBXZSB3YW50IHRvIGJlIGFibGUgdG8gZWF0 IGFwcGxlcy4gSGV5LCBJIGFncmVlIHdpdGggdGhhdC4gDQpOYXR1cmFsIHRl ZXRoIGFyZSBncmVhdC4NCg0KQnV0IGhhdmUgeW91IGV2ZXIgc2VlbiBzb21l b25lIHdobyB3YXMgZm9yY2VkIHRvIGVuZHVyZSBhIGNvbG9uZWN0b215PyAN ClNvbWVvbmUgd2hvIG5vdyB3aWxsIGJlIHNwZW5kaW5nIHRoZSByZXN0IG9m IHRoZWlyIGxpZmUgY2FycnlpbmcgYSBiYWcgYXJvdW5kPyANCg0KSW5jcmVk aWJseSwgdGhpcyBpcyBhbiBhcmVhIChlZmZlY3RpdmUgcHJldmVudGlvbikg d2hlcmUgZXZlbiB0aGUgc3RhdW5jaGVzdCANCk1EJ3MgQUdSRUUgd2l0aCB1 cyEhIENhbiB5b3UgYmVsaWV2ZSBpdD8gSWYgdGhleSBrbmV3IHlvdSBoYWQg YWNjZXNzIHRvIA0KdGhlIGdyZWF0ZXN0IGNvbG9uIGNsZWFuc2UgaW4gdGhl IHdvcmxkLCBJIGJldCB0aGV5IG1pZ2h0IGV2ZW4gYWR2aXNlIHlvdSANCnRv IGRvIGl0IHJlZ3VsYXJseS4gIE5PLCBJJ20gbm90IGtpZGRpbmcgaWYuLi4g DQoNClRoaXMgc3ViamVjdCBpcyBub3QgZXZlbiB1cCBmb3IgZGViYXRlLiBJ dCdzIGEgcHJvdmVuIGZhY3QuIFRoZSBwcm9ibGVtIGlzLCANCm1vc3QgcGVv cGxlIGFyZSBub3QgZG9pbmcgYW55dGhpbmcgYWJvdXQgaXQuIFBsZWFzZSBk b24ndCBiZSBvbmUgb2YgdGhlbS4gDQoNCioqKipXQVJOSU5HKioqKiogDQoN ClRoZSBuZXh0IHNlY3Rpb24gb2YgdGhpcyBlbWFpbCBjb250YWlucyBncmFw aGljIG1hdGVyaWFsIHdoaWNoIG1heSBub3QgDQpiZSBzdWl0YWJsZSBmb3Ig c3F1ZWFtaXNoIGluZGl2aWR1YWxzLiANCg0KTGV0J3MgdGFsayBzdG9vbHMu IA0KDQpUaGUgc3Rvb2wgdGVsbHMgeW91IGEgbG90IGFib3V0IHlvdXIgY29s b24gaGVhbHRoLiBJZiBpdCdzIGRhcmsgYnJvd24gaW4gDQpjb2xvciwgYW5k IGl0IHNpbmtzLCBhbmQgaXQgc3RpbmtzLCB0aGF0J3Mgbm90IGdvb2QuIEFu ZCBkb24ndCBmZWVsIGJhZCwgDQp0aGF0J3MgdGhlIHdheSBtb3N0IHBlb3Bs ZSBhcmUuIFdoYXQgeW91IHdhbnQgdG8gc2VlIGlzIGxpZ2h0IGJyb3duIGNv bG9yLCANCndoaWNoIG1lYW5zIGl0J3MgZnVsbCBvZiBmcmVzaCBiaWxlIGZy b20gdGhlIGxpdmVyLCB2ZXJ5IG1pbGQgb2RvciwgYW5kIGEgDQpzdG9vbCB0 aGF0IGZsb2F0cy4gV2UncmUgdGFsa2luZyBsb3ctZGVuc2l0eSBoZXJlIGZv bGtzLiBUaGUgbW9yZSBjb21wYWN0aW9uIA0KeW91IGhhdmUgdGhlIGRhcmtl ciB0aGUgY29sb3IgYW5kIHRoZSBmYXN0ZXIgaXQgc2lua3MuIA0KDQpDb21w YWN0aW9uIGlzIG5vdCBnb29kLiBBbHNvLCBtb3ZpbmcgYm93ZWxzIHNob3Vs ZCBiZSBTSU1QTEUuIElmIHRoZSB2ZWlucyANCmFyZSBwb3BwaW5nIG91dCBv ZiB5b3VyIG5lY2sgYW5kIHlvdSBmZWVsIGxpa2UgeW91ciBkb2luZyB0aGUg YmVuY2ggcHJlc3MsIA0KeW91IE5FRUQgdG8gY2xlYW4geW91ciBpbnRlc3Rp bmVzLiBJZiB5b3UgaGF2ZSB0aW1lIHRvIHJlYWQgd2hlbiAiZG9pbmcgeW91 ciANCmJ1c2luZXNzIiwgeW91IG5lZWQgdG8gY2xlYW4gb3V0IHlvdXIgZGln ZXN0aXZlIHRyYWN0LiBJZiB5b3UgImdvIiBvbmNlIGEgDQpkYXksIG9yIHdv cnNlLCBvbmNlIGV2ZXJ5IHR3byBvciB0aHJlZSBkYXlzLCB5b3UgbmVlZCB0 byBjbGVhbiBvdXQgeW91ciBwdW1iaW5nIA0KcXVpdGUgdGhvcm91Z2hseSB2 ZXJ5IHNvb24uIElmIHlvdSBoYXZlIGEgYm93ZWwgbW92ZW1lbnRzIGxlc3Mg ZnJlcXVlbnRseSANCnRoYW4gb25jZSBldmVyeSB0aHJlZSBkYXlzLCBjb25z aWRlciB0aGlzIG1lc3NhZ2UgY29tZXMgdG8geW91IG9uIHRoZSB3aW5ncyAN Cm9mIGEgd2hpdGUgZG92ZS4gUGF5IHBhcnRpY3VsYXJseSBjbG9zZSBoZWVk IHRvIGFsbCBpdCBpbXBhcnRzLiBZb3UsIGZhciBtb3JlIA0KdGhhbiBtb3N0 LCB3aWxsIGJlbmVmaXQgZW5vcm1vdXNseS4NCg0KQSBsaWZlc3R5bGUgdGhh dCBoYXMgaW5jbHVkZWQgdGFraW5nIHBoYXJtYWNldXRpY2FsIGRydWdzIG9m IGFueSBraW5kLCBlYXRpbmcgDQp0b28gbXVjaCBjb29rZWQgZm9vZCwgcHJv Y2Vzc2VkL3JlZmluZWQgZm9vZHMsIG1lYXQsIGRhaXJ5IGFuZCBwb3VsdHJ5 LCBjYXVzZWQgDQp5b3VyIGJvZHkgdG8gYmVjb21lIGNvbmdlc3RlZCB3aXRo IG11Y3VzLiBUaGlzIGluIHR1cm4gaGFzIHdlYWtlbmVkIHRoZSBmdW5jdGlv biANCm9mIHlvdXIgZGlnZXN0aXZlIHN5c3RlbSBhbmQgZWxpbWluYXRpb24g b3JnYW5zIHN1Y2ggYXMgdGhlIGNvbG9uLCBsaXZlciBhbmQgDQpraWRuZXlz LiAgQWxsIG9mIHdoaWNoIGxlYWRzIHRvIGEgdmVyeSBhY2lkIGNvbmRpdGlv biBvZiBwSCBpbiB0aG9zZSBib2R5J3MgDQp0aXNzdWVzIHdoaWNoIHNob3Vs ZCBiZSBtb3JlIGFsa2FsaW5lLg0KDQpBIHBvbGx1dGVkIGludGVzdGluYWwg dHJhY3QgbWVhbnMgZGlydHkgYmxvb2QsIHBvb3IgZGlnZXN0aW9uIGFuZCBs b3cgZW5lcmd5LiANCllvdXIgaG9ybW9uZXMgYW5kIGVtb3Rpb24gc3RhdGUg YXJlIGFsc28gZ3JlYXRseSBpbXBhY3RlZCBuZWdhdGl2ZWx5Lg0KDQpXaGVu IHRoZSBpbnRlc3RpbmVzIGhhdmUgdG9vIG11Y2ggd2FzdGUgbWF0dGVyLCBw YXJhc2l0ZXMsIGZ1bmd1cyBhbmQgaGFybWZ1bCANCmJhY3RlcmlhIHRoZXJl IHJlc3VsdHMgYSBzZXJpb3VzIGludGVyZmVyZW5jZSB3aXRoIHRoZSBkaWdl c3RpdmUgcHJvY2Vzcy4gRXZlbiANCmlmIGEgcGVyc29uJ3MgaW50ZXN0aW5h bCB0cmFjdCB3ZXJlIHBvbGx1dGVkIHdpdGgganVzdCBhIG1pbGQgYW1vdW50 IG9mIHRoaXMgDQp1bmRlc2lyYWJsZSBmaWx0aCwgaGUgb3Igc2hlIHdvdWxk IGhhdmUgc2x1Z2dpc2ggcGVyaXN0YWx0aWMgYWN0aW9uLCB3aGljaCBjYXVz ZXMgDQpjb25zdGlwYXRpb24uIEhvdyBkb2VzIG9uZSdzIGJvZHkgYWRqdXN0 IHRvIGEgZGlldCBmdWxsIG9mIGZvb2QgdGhhdCBoYXMgYmVlbiANCmFkdWx0 ZXJhdGVkIGJ5IGNvb2tpbmcsIHByb2Nlc3NpbmcgYW5kIHJlZmluaW5nIC0g ZGVhZCBmb29kPyBBY2NvcmRpbmcgdG8NClZpY3RvcmlhIEJvdXRlbmtvIGlu IGhlciBib29rLCAiMTIgU3RlcHMgdG8gUmF3IEZvb2QiLCAiVGhlIGJvZHkg Y3JlYXRlcyBtdWN1cyANCmFuZCB1c2VzIHRoaXMgbXVjdXMgYXMgYSBmaWx0 ZXIuIEFsbCB0aGUgc3VyZmFjZXMgb2YgdGhlIGRpZ2VzdGl2ZSB0cmFjdCB0 aGF0IA0KYXJlIGRlc2lnbmVkIHRvIGFic29yYiB0aGUgbnV0cmllbnRzIGZy b20gZm9vZCBiZWNvbWUgY292ZXJlZCB3aXRoIG11Y3VzIGZpbG0gDQp0aGF0 IHByb3RlY3RzIHRoZSBibG9vZCBmcm9tIHRveGlucy4gVGhlIG11Y3VzIGZp bG0gYmVnaW5zIGluIHRoZSBtb3V0aCBhbmQgDQpzaW51c2VzIGFuZCBjb250 aW51ZXMgYWxsIHRoZSB3YXkgdGhyb3VnaCB0aGUgc21hbGwgYW5kIGxhcmdl IGludGVzdGluZXMuIE1hbnkgDQpwZW9wbGUgY2FuIHNlZSB0aGlzIGxpbmlu ZyBhcyBhIHdoaXRlIGNvYXRpbmcgb24gdGhlaXIgdG9uZ3VlLiBUaGUgbW9y ZSBoYXJtZnVsIA0KdGhlIGZvb2Qgc3Vic3RhbmNlcyBhcmUgdG8gdGhlIGJv ZHksIHRoZSBtb3JlIHRoaXMgbXVjdXMgZmlsbSBidWlsZHMgdXAgYmVjb21p bmcgDQp0aGlja2VyIGFuZCBoYXJkZXIuIFBvcnRpb25zIG9mIHRoaXMgdGhp Y2sgbXVjdXMgbGluaW5nIGdldCBwdXNoZWQgaW50byBwb2NrZXRzIA0KaW4g dGhlIGludGVzdGluZXMgY2FsbGVkIGRpdmVydGljdWxpIGFzIHdlIGNyYW0g dGhyb3VnaCBtb3JlIGFuZCBtb3JlIGRlYWQgZm9vZCANCmludG8gdGhlIGRp Z2VzdGl2ZSB0cmFjdCBpbiBhbiBlZmZvcnQgdG8gc3F1ZWV6ZSBzb21lIG51 dHJpdGlvbmFsIHZhbHVlIG91dCBvZiBpdC4gDQogICANCiJZb3UgbWF5IGFz azogV2hhdCBpcyB0aGlzIG11Y3VzIG1hZGUgb2Y/IFRoZSBodW1hbiBib2R5 LCBicmlsbGlhbnQgaW4gaXRzIGRlc2lnbiwgDQpjcmVhdGVzIHRoZSBtdWN1 cyBmcm9tIHRoZSBkZWFkIGZvb2QgaXRzZWxmISBUaGlzIG11Y3VzIGNvdmVy cyBvdXIgZW50aXJlIGRpZ2VzdGl2ZSANCnRyYWN0IHRvIHByZXZlbnQgdXMg ZnJvbSBhYnNvcmJpbmcgdGhlIHRveGlucyBpbiBhZHVsdGVyYXRlZCBmb29k cyB0aGF0IHdvdWxkIG1ha2UgDQp0aGUgYm9keSBzaWNrLiBCZWNhdXNlIG9m IHRoZSBleGlzdGVuY2Ugb2YgdGhpcyBtdWNvaWQgcGxhZ3VlIGxheWVyLCBv dXIgbnV0cmllbnQgDQphc3NpbWlsYXRpb24gYmVjb21lcyBsb3dlciBhbmQg bG93ZXIgYXMgd2UgZ2V0IG9sZGVyLiBUaGUgbXVjb2lkIHBsYWd1ZSBwcm90 ZWN0cyANCnVzIGZyb20gYWJzb3JiaW5nIHRvbyBtdWNoIHRveGljaXR5IGJ1 dCBhdCB0aGUgc2FtZSB0aW1lIHJlZHVjZXMgdGhlIGFic29yYnRpb24gDQpv ZiBtdWNoIG9mIHRoZSBudXRyaXRpb24gbmVlZGVkIGJ5IHRoZSBib2R5LiBB ZnRlciBhIG51bWJlciBvZiBjb25zZWN1dGl2ZSB5ZWFycyANCmFuZCBkZWNh ZGVzIG9mIGVhdGluZyB0b28gbXVjaCBkZWFkIGZvb2QsIHdlIGRldmVsb3Ag c2V2ZXJlIG51dHJpdGlvbmFsIGRlZmljaWVuY2llcywgDQpiZWNvbWUgbGVz cyBlbmVyZ2V0aWMgYW5kIGZpbmFsbHkgbGVhcm4gd2UgYXJlIHNpY2sgd2l0 aCBkaXNlYXNlcy4NCg0KIldoZW4gd2UgZ28gb24gYSByYXctbGl2ZSBmb29k IGFuZCBzdGF5IHdpdGggaXQsIHRoaXMgbXVjb2lkIHBsYWd1ZSBjYW4gYmUg ZGlzc29sdmVkLiANCldpdGggdGhlIGFpZCBvZiBoZXJiYWwgcHJlcGFyYXRp b25zLCBnZW5lcm91cyBhbW91bnRzIG9mIHdhdGVyIGNvbnN1bXB0aW9uIGRh aWx5IA0KYW5kIGV4ZXJjaXNlLCB0aGUgYm9keSB3aWxsIGVsaW1pbmF0ZSBp dCBmYXN0ZXIuIElmIHdlIHN0YXkgd2l0aCBhIGxpdmUtZm9vZCBkaWV0IA0K bG9uZyBlbm91Z2gsIHRoZSBib2R5IHdpbGwgY29tcGxldGVseSBkaXNzb2x2 ZSB0aGlzIG11Y29pZCBwbGFndWUgY29hdGluZyIuDQoNCldoZW4geW91IGRv IHRoZSBjbGVhbnNlLCBmb3IgdGhlIGZpcnN0IGZldyBkYXlzLi4uLnRoaW5n cyBpbiB5b3VyIGxpZmUgYXJlIG5lZWRpbmcgDQp0byBiZSByZWFkanVzdGVk LiBCdXQgeW91IGtub3cgeW91J3JlIGNsZWFuc2VkIHdoZW4geW91IHNlZSB0 aGUgYWJvdmUgZ29vZCBzdHVmZiANCmhhcHBlbmluZywgYW5kIHlvdSBhcmUg ZWxpbWluYXRpbmcgYW4gYXZlcmFnZSBvZiAyLTMgdGltZXMgcGVyIGRheS4g DQoNCkNsZWFuc2luZyB5b3VyIGNvbG9uIHdpdGggaGVyYmFsIHByZXBhcmF0 aW9ucyBhcyBhIHByZXZlbnRhdGl2ZSBzdGVwIGlzIGEgMjEtZGF5IA0KcHJv Y2Vzcy4gSXRzIGFsc28gdmVyeSBlY29ub21pY2FsIGFuZCB3b3J0aCBldmVy eSBjZW50ISBZb3UgbWF5IGJlIHZlcnkgc3VycHJpc2VkIA0KYXQgc29tZSBv ZiB0aGUgYmVuZWZpdHMgeW91IHdpbGwgcmVjZWl2ZSwgYmVzaWRlcyBqdXN0 IGxvc2luZyAxLTUgbGJzIG9mIGFjY3VtdWxhdGVkIA0Kd2FzdGUgbWF0dGVy IGZyb20geW91ciBib2R5IGFuZCBicmlnaHRlbmluZyB5b3VyIGZ1dHVyZSBo ZWFsdGguIA0KDQpQZW9wbGUgaGF2ZSByZXBvcnRlZCBtb3JlIGVuZXJneSwg bGVzcyBhbGxlcmdpZXMsIGNsZWFyaW5nIG9mIGFjbmUsIGNlc3NhdGlvbiBv ZiANCm1pZ3JhaW5lcywgYW5kIG1hbnkgb3RoZXIgcmVzdWx0cywgbm90IHRv IG1lbnRpb24gcmVzdG9yZWQgcmVndWxhcml0eS4gV2hlbiB5b3VyIA0KYm9k eSBpcyB2b2lkIG9mIG9sZCwgcG9pc29ub3VzIHRveGlucyB0aGF0IGFyZSBj b25zdGFudGx5IGJlaW5nIHJlYWJzb3JiZWQgdGhyb3VnaCANCnRoZSBjb2xv biB3YWxscywgaXQgY2FuIGJlZ2luIHRvIGhlYWwgYWdhaW4uIEFuZCB3aGVu IHRoZSBjb2xvbiB3YWxscyBhcmUgY2xlYW4sIHRoZSANCmdvb2QgbnV0cmll bnRzIGZyb20geW91ciAgZnJlc2ggbGl2ZSBmb29kIGFuZCBuYXR1cmFsIHdo b2xlZm9vZCBzdXBwbGVtZW50cyBjYW4gDQpiZSBhYnNvcmJlZCBhZ2Fpbi4g WW91IHdpbGwgYmUgdGhyaWxsZWQgd2l0aCB0aGUgaW1wcm92ZW1lbnRzIGlu IHlvdXIgaGVhbHRoLiANCg0KQXQgdGhpcyBwb2ludCB5b3UgbWF5IGJlIHRo aW5raW5nIHlvdSB3aWxsIGxlYXZlIGl0IHVwIHRvIGZhdGUgdG8gZGV0ZXJt aW5lIHdoYXQgDQp5b3Ugc2hvdWxkIGRvIGFib3V0IGNsZWFuaW5nIG91dCB0 aGUgaW5zaWRlIG9mIHlvdXIgb3duIGJvZHksIG9yIHlvdSBrbm93IHRoaXMg aXMgDQpub3QgbGlrZWx5IHRvIGhhcHBlbiBzb29uIGVub3VnaCB0byBzYXRp c2Z5IHlvdSBhbmQgeW91J3JlIHJlYWR5IHRvIGRvIHNvbWV0aGluZyANCmFi b3V0IGl0IHlvdXJzZWxmLiANCg0KT3VyIGNvbXBhbnkgd291bGQgbG92ZSB0 byBzZW5kIHlvdSBtb3JlIGluZm9ybWF0aW9uDQpyZWdhcmRpbmcgY2xlYW5z aW5nIGFuZCBoZWFsdGggdGhyb3VnaCBwcm9wZXIgbnV0cml0aW9uLg0KDQoN CkZvciBhIGZyZWUgaW5mb3JtYXRpb24gcGFjayB2aWEgc25haWwgbWFpbCAo VVMgcG9zdGFsIHNlcnZpY2UpDQpzZW5kIGFuIGVtYWlsIHRvOiAgaGVyYmxp ZmU3QG5ldHNjYXBlLm5ldA0KDQpPciB5b3UgY2FuIGNhbGwgODAwLTM5My03 OTU0DQoNCg0KTWFrZSBzdXJlIHRvIGluY2x1ZGUgeW91ciBuYW1lLCBtYWls aW5nIGFkZHJlc3MsIGFuZA0KdGVsZXBob25lIG51bWJlciBhbmQgd2UnbGwg bWFpbCBhIGZyZWUgaW5mbyBwYWNrIA0KcmlnaHQgb2ZmIHRvIHlvdS4NCg0K DQpXZSBkbyBub3QgcmVwbHkgd2l0aCBvdXIgZXh0ZW5zaXZlIGluZm9ybWF0 aW9uIHBhY2sgdGhyb3VnaCBlbWFpbC4NCg0KDQpSZW1lbWJlciwgdGhpcyBp bmZvcm1hdGlvbiBvbmx5IGNvbWVzIHZpYSBzbmFpbCBtYWlsIGFuZCB5b3Vy IGxvY2FsIG1haWxtYW4sIA0Kc28gcGxlYXNlIGRvbid0IGFzayBmb3IgZW1h aWwgcmVzcG9uc2VzLiANCg0KDQpSZW1lbWJlciB0byBpbmNsdWRlIHlvdXIg Y29tcGxldGUgcGh5c2ljYWwgYWRkcmVzcy4NCg0KDQpUaGFua3MgYW5kIGdv b2QgaGVhbHRoLg0KDQoNCg0KSWYgeW91IHdpc2ggdG8gYmUgdGFrZW4gb2Zm IHRoaXMgbGlzdCBzZW5kIGFuIA0KZW1haWwgdG8gdGhlIGZvbGxvd2luZyBh ZGRyZXNzLg0KDQpub2hlcmJzQGV4Y2l0ZS5jb20NCg0KDQpUaGFuayBZb3UN CjUwNzJTQnNlNi0zMjBTcUdDMjI3NHZFVGU2LTA5MWFzTG02Njc2aFF1VDgt NzI3TWJZQjMxbDUw ---------------------- multipart/mixed attachment--From noreply@sourceforge.net Mon Aug 26 21:38:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Aug 2002 13:38:16 -0700 Subject: [Expat-bugs] [ expat-Bugs-596678 ] XML_ParserReset not documented Message-ID: Bugs item #596678, was opened at 2002-08-18 00:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596678&group_id=10127 >Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: XML_ParserReset not documented Initial Comment: Reference.html contains no reference to XML_ParserReset. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-26 16:38 Message: Logged In: YES user_id=3066 Fixed in doc/reference.html revision 1.29. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596678&group_id=10127 From noreply@sourceforge.net Mon Aug 26 22:24:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Aug 2002 14:24:02 -0700 Subject: [Expat-bugs] [ expat-Bugs-596555 ] rephrase "xml p.i." message Message-ID: Bugs item #596555, was opened at 2002-08-17 16:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596555&group_id=10127 Category: None >Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mike Brown (mike_j_brown) >Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: rephrase "xml p.i." message Initial Comment: expat.c contains this message: XML_L("xml processing instruction not at start of external entity"), but "xml processing instruction" is a misnomer. Although this message appears when a processing instruction with the illegal target "xml" is encountered, the error message should not imply that the structure that belongs at the start of an external entity is a processing instruction. I suggest changing this phrase to the more correct "XML or text declaration not at start of external entity" so as not to perpetuate common misconceptions. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-26 17:24 Message: Logged In: YES user_id=3066 Fixed in lib/xmlparse.c revision 1.73. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596555&group_id=10127 From noreply@sourceforge.net Mon Aug 26 22:26:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Aug 2002 14:26:35 -0700 Subject: [Expat-bugs] [ expat-Bugs-599470 ] (1.95.4) runtests fails on MacOSX Message-ID: Bugs item #599470, was opened at 2002-08-23 20:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=599470&group_id=10127 >Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Erwin (jerwin) Assigned to: Nobody/Anonymous (nobody) Summary: (1.95.4) runtests fails on MacOSX Initial Comment: I attempted to run "make check". However, the runtests script is erroneous labeled as a "sh" script. It runs properly under "bash". I'm running MacOSX 10.1. I'm not sure who's to blame for this-- the runtests script is listed as "generated by libtool". ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-26 17:26 Message: Logged In: YES user_id=3066 Does it fail to run using sh on Mac OS X? Not sure what the right thing to do is if it doesn't -- libtool is evil. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=599470&group_id=10127 From noreply@sourceforge.net Mon Aug 26 22:28:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Aug 2002 14:28:33 -0700 Subject: [Expat-bugs] [ expat-Bugs-595532 ] xmlwf -x not reading the external DTD Message-ID: Bugs item #595532, was opened at 2002-08-15 10:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=595532&group_id=10127 Category: None >Group: Not a Bug >Status: Closed Resolution: Rejected Priority: 5 Submitted By: Michel Rodriguez (mirod) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xmlwf -x not reading the external DTD Initial Comment: xmlwf test_ext_ent.xml gives me an error on an undefined entity despite it being defined in the (external) DTD >xmlwf -x test_ext_ent.xml test_ext_ent.xml:2:5: undefined entity --- test_ext_ent.xml --- &ent; --- test_ext_ent.dtd --- It has no problem if I do xmlwf -p test_ext_ent.xml Shouldn't -x find the entity declaration in the DTD? That's with expat 1.95.4 -- Michel ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-26 17:28 Message: Logged In: YES user_id=3066 Karl's right -- xmlwf is doing the right thing already. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-16 09:20 Message: Logged In: YES user_id=290026 Maybe, but that is a matter of specifications, not a bug. Consider this: external entity references can be anything, not just references to files. You could have an URL, or some Public Id for instance. But xmlwf only provides external entity reference resolution for files. >From that point of view it makes actual sense that it is turned off by default, and consequently, external entity reference resolution should only be turned on if you know that all external references in your xml document can be resolved as files. ---------------------------------------------------------------------- Comment By: Michel Rodriguez (mirod) Date: 2002-08-16 01:24 Message: Logged In: YES user_id=72556 Don't you think that using xmlwf with no options on a well-formed xml file should not return an error, even if the file is not standalone? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-15 11:14 Message: Logged In: YES user_id=290026 I am not the expert on xmlwf, but by looking at the code, it appears that parameter entity parsing is turned off when -p is not specified. Since Expat considers an external DTD a parameter entity - check reference.html - it will consequently not read it. Therefore the entity declaration for &ent; will be missing. Btw, -p implies -x, AFAIK. This is not a bug, as far as I can tell, but I leave it open for Fred to comment. Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=595532&group_id=10127 From noreply@sourceforge.net Mon Aug 26 22:33:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Aug 2002 14:33:18 -0700 Subject: [Expat-bugs] [ expat-Bugs-597878 ] expat-1.95.4 . Warning during make Message-ID: Bugs item #597878, was opened at 2002-08-20 14:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=597878&group_id=10127 >Category: Build control Group: Platform Specific >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat-1.95.4 . Warning during make Initial Comment: Hi, during make for expat1-95.4 . I am getting this warning mesage (libtool: link: warning: this platform does not like uninstalled shared libraries") Is this Normal ? I am trying to install it in HP UX 11.0(64 Bit ) with perl5.6.1 . I need to build XML Parser on top of this . boi48@/tmp/sanjay/XMLP/expat-1.95.4% ./configure checking build system type... hppa2.0w-hp-hpux11.00 checking host system type... hppa2.0w-hp-hpux11.00 checking for gcc... no checking for cc... cc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether cc accepts -g... yes checking for non-GNU ld... /bin/ld checking if the linker (/bin/ld) is GNU ld... no checking for /bin/ld option to reload object files... -r checking for BSD-compatible nm... /bin/nm -p checking whether ln -s works... yes checking how to recognise dependant libraries... file_magic (s[0-9][0-9][0-9]|PA-RISC[0-9].[0-9]) shared library checking command to parse /bin/nm -p output... ok checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for cc option to produce PIC... +Z checking if cc PIC flag +Z works... yes checking if cc static flag -Wl,-a -Wl,archive works... yes checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.lo... yes checking whether the linker (/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... relink checking whether stripping libraries is possible... no checking dynamic linker characteristics... hpux11.00 dld.sl checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes creating libtool checking for gcc... (cached) cc checking whether we are using the GNU C compiler... (cached) no checking whether cc accepts -g... (cached) yes checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking whether byte ordering is bigendian... yes checking for cc option to accept ANSI C... none needed checking for an ANSI C-conforming const... yes checking for off_t... yes checking for size_t... yes checking for working memcmp... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... no checking for memmove... yes checking for bcopy... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h boi48@/tmp/sanjay/XMLP/expat-1.95.4% make /bin/sh ./libtool --silent --mode=compile cc -g - I./lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile cc -g - I./lib -I. -o lib/xmltok.lo -c lib/xmltok.c /bin/sh ./libtool --silent --mode=compile cc -g - I./lib -I. -o lib/xmlrole.lo -c lib/xmlrole.c /bin/sh ./libtool --silent --mode=link cc -g -I./lib -I. - no-undefined -version-info 3:0:3 -rpath /usr/local/lib -o libeo cc -g -I./lib -I. -o xmlwf/xmlwf.o -c xmlwf/xmlwf.c cc -g -I./lib -I. -o xmlwf/xmlfile.o -c xmlwf/xmlfile.c cc -g -I./lib -I. -o xmlwf/codepage.o -c xmlwf/codepage.c cc -g -I./lib -I. -o xmlwf/readfilemap.o -c xmlwf/readfilemap.c /bin/sh ./libtool --silent --mode=link cc -g -I./lib - I. -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xa libtool: link: warning: this platform does not like uninstalled shared libraries libtool: link: `xmlwf/xmlwf' will be relinked during installation ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-26 17:33 Message: Logged In: YES user_id=3066 It sounds like the kind of thing to expect with libtool, but we don't have enough platform knowledge to do anything about this. If HP-UX doesn't work well with non-installed dynamic libraries, then this is a reasonable behavior. If it's not true, then a bug should be filed against libtool: http://savannah.gnu.org/projects/libtool/ I'm convinced libtool is evil. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=597878&group_id=10127 From noreply@sourceforge.net Mon Aug 26 22:34:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Aug 2002 14:34:42 -0700 Subject: [Expat-bugs] [ expat-Bugs-600479 ] error decoding UTF-8 triplet Message-ID: Bugs item #600479, was opened at 2002-08-26 14:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 Category: www.libexpat.org Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: error decoding UTF-8 triplet Initial Comment: On Windows, when reading the UTF-8 sequence "EF BA BF", utf8_isInvalid3 returns TRUE, when it should return FALSE. This UTF-8 sequence encodes to "FEBF" as UCS-2 (Unicode), but as a result of utf8_isInvalid3 returning TRUE, an error results and the character isn't decoded properly. This is using expat 1.95.4. Attached is a simple XML file which illustrates the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 From noreply@sourceforge.net Mon Aug 26 22:37:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Aug 2002 14:37:14 -0700 Subject: [Expat-bugs] [ expat-Bugs-596059 ] Parser !initialized when XML_DTD undef Message-ID: Bugs item #596059, was opened at 2002-08-16 10:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596059&group_id=10127 Category: None Group: None >Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: Parser !initialized when XML_DTD undef Initial Comment: The parser does not seem to be properly initialized if XML_DTD is not defined. The dtdInit functions is only called if XML_DTD is defined, but dtdInit itself has internal #ifdef XML_DTD which seems to indicate it should be called with or without XML_DTD. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-26 17:37 Message: Logged In: YES user_id=290026 Convinced it is a duplicate. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-16 10:32 Message: Logged In: YES user_id=290026 This seems to be a duplicate of bug # 584183 which has been fixed in CVS. Please check out the latest revision from CVS and report if that resolves it for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596059&group_id=10127 From noreply@sourceforge.net Mon Aug 26 22:45:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Aug 2002 14:45:08 -0700 Subject: [Expat-bugs] [ expat-Bugs-597887 ] ld: Mismatched ABI (not an ELF file) for Message-ID: Bugs item #597887, was opened at 2002-08-20 14:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=597887&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ld: Mismatched ABI (not an ELF file) for Initial Comment: I installed expat1.95.4 . Now when i build the XML- PARSER2.31 . 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/xs 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: 2002-08-26 17:45 Message: Logged In: YES user_id=3066 So what's the output of "file /usr/local/lib/libexpat.so" ? Are there other Expat library files lurking? What platform? It's hard to diagnose this without more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=597887&group_id=10127 From noreply@sourceforge.net Mon Aug 26 22:48:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Aug 2002 14:48:04 -0700 Subject: [Expat-bugs] [ expat-Bugs-564275 ] Test 11 in stream.t fails Message-ID: Bugs item #564275, was opened at 2002-06-04 05:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=564275&group_id=10127 Category: XML::Parser (inactive) >Group: Third-party Bug >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Test 11 in stream.t fails Initial Comment: System: Linux 2.4.10-4GB i686 Expat-Version: 1.95.3 Perl-Version: 5.6.1 in stream.t, problem with encoding: $string differs from $expected at index 333: $string is result of parsing a document in ISO-8859-1 encoding, input contains character chr(160) which sneaks into output (UTF-8 encoding) unchanged, instead of being converted to chr(192)chr(160). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-26 17:48 Message: Logged In: YES user_id=3066 Appearantly the XML::Parser community doesn't include anyone with enough time to look into this. Since this is most likely a problem specific to XML::Parser, I'm closing this as a 3rd-party bug. If someone can provide an equivalent test using the C API or xmlwf, a new bug report can be opened. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-07-31 11:40 Message: Logged In: YES user_id=290026 Fred to follow up. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-21 10:14 Message: Logged In: YES user_id=3066 This report can't be assigned to Clark Cooper since he's no longer active on this project. I'll see if I can round up someone to help respond to XML::Parser issue reports -- I don't know that anyone currently on this project knows much about the Perl bindings. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-07 02:13 Message: Logged In: NO Sorry, was a typo indeed. After parsing the test string (in stream.t) following expressions evaluate to true: ord( substr($string, 332, 1) ) == 160; ord( substr($expected, 332, 1) ) == 194; ord( substr($expected, 333, 1) ) == 160; The test failed yesterday on my freshly installed Suse 8.0 System at home, the expat-library was compiled on Suse 7.3 here at work, though. Some ideas, what's responsible for this test failing? Thank you. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 13:59 Message: Logged In: YES user_id=290026 Works for me. Expat 1.95.3 returns 0xC2 0xA0 which corresponds to chr(194) chr(160). I assume you made a typo, since chr(192) = 0xC0 is not valid for the first byte in a UTF-8 sequence. Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=564275&group_id=10127 From tim.crook@adobe.com Mon Aug 26 22:51:25 2002 From: tim.crook@adobe.com (Tim Crook) Date: Mon, 26 Aug 2002 17:51:25 -0400 Subject: [Expat-bugs] Problem with decoding UTF-8 triplet and expat 1.95.4 Message-ID: <311000B0752ED211B61700805F0D6B0902FDC357@ottmail3.jetform.com> On Windows, when reading the UTF-8 sequence "EF BA BF", utf8_isInvalid3 returns TRUE, when it should return FALSE. This UTF-8 sequence encodes to "FEBF" as UCS-2 (Unicode), but as a result of utf8_isInvalid3 returning TRUE, an error results and the character isn't decoded properly. Here is a simple XML file which illustrates the problem: xxx To see the problem, replace xxx with the string value for "EF BA BF". _________________________________________ Tim Crook Computer Scientist Adobe Systems Canada Inc. 785 Carling Avenue Ottawa, Ontario Canada K1S 5H4 Phone: +1 613.751.4800 Ext 5734 Fax: +1 613.594.8886 E-mail: tim.crook@adobe.com From tim.crook@adobe.com Mon Aug 26 23:33:25 2002 From: tim.crook@adobe.com (Tim Crook) Date: Mon, 26 Aug 2002 18:33:25 -0400 Subject: [Expat-bugs] RE: [ expat-Bugs-600479 ] error decoding UTF-8 triplet Message-ID: <311000B0752ED211B61700805F0D6B0902FDC358@ottmail3.jetform.com> Hmm... This problem seems to be caused by bad code generation in MSDEV 6, SP5. When I build with debug mode, I get an error. When I compile it with release mode, it works. _________________________________________ Tim Crook Computer Scientist Adobe Systems Canada Inc. > 785 Carling Avenue > Ottawa, Ontario > Canada K1S 5H4 > Phone: +1 613.751.4800 Ext 5734 Fax: +1 613.594.8886 E-mail: tim.crook@adobe.com From tim.crook@adobe.com Mon Aug 26 23:55:27 2002 From: tim.crook@adobe.com (Tim Crook) Date: Mon, 26 Aug 2002 18:55:27 -0400 Subject: [Expat-bugs] RE: RE: [ expat-Bugs-600479 ] error decoding UTF-8 triplet Message-ID: <311000B0752ED211B61700805F0D6B0902FDC359@ottmail3.jetform.com> I got it wrong. I run into the problem in both debug and release modes with MSDEV 6. The problem as originally stated holds true. > -----Original Message----- > From: Tim Crook > Sent: Monday, August 26, 2002 6:33 PM > To: 'expat-bugs@libexpat.org' > Subject: RE: [ expat-Bugs-600479 ] error decoding UTF-8 triplet > > Hmm... > > This problem seems to be caused by bad code generation in MSDEV 6, SP5. > When I build with debug mode, I get an error. When I compile it with > release mode, it works. > > _________________________________________ > Tim Crook > Computer Scientist > > Adobe Systems Canada Inc. > 785 Carling Avenue > Ottawa, Ontario > Canada K1S 5H4 > > Phone: +1 613.751.4800 Ext 5734 > Fax: +1 613.594.8886 > E-mail: tim.crook@adobe.com > From noreply@sourceforge.net Tue Aug 27 01:30:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Aug 2002 17:30:24 -0700 Subject: [Expat-bugs] [ expat-Bugs-600479 ] error decoding UTF-8 triplet Message-ID: Bugs item #600479, was opened at 2002-08-26 17:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 Category: www.libexpat.org Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: error decoding UTF-8 triplet Initial Comment: On Windows, when reading the UTF-8 sequence "EF BA BF", utf8_isInvalid3 returns TRUE, when it should return FALSE. This UTF-8 sequence encodes to "FEBF" as UCS-2 (Unicode), but as a result of utf8_isInvalid3 returning TRUE, an error results and the character isn't decoded properly. This is using expat 1.95.4. Attached is a simple XML file which illustrates the problem. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-26 20:30 Message: Logged In: YES user_id=290026 Yes, this is a bug. utf8_isInvalid3 tries to detect the invalid XML sequences (*not* invalid unicode) EF BF BE and EF BF BF, but only checks the first and third byte, not the second one. Fix alread checked into CVS (xmltok.c 1.23). Please check out and test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 From noreply@sourceforge.net Tue Aug 27 12:35:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 04:35:14 -0700 Subject: [Expat-bugs] [ expat-Bugs-600479 ] error decoding UTF-8 triplet Message-ID: Bugs item #600479, was opened at 2002-08-26 17:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 >Category: None >Group: Test Required Status: Open Resolution: Fixed >Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: error decoding UTF-8 triplet Initial Comment: On Windows, when reading the UTF-8 sequence "EF BA BF", utf8_isInvalid3 returns TRUE, when it should return FALSE. This UTF-8 sequence encodes to "FEBF" as UCS-2 (Unicode), but as a result of utf8_isInvalid3 returning TRUE, an error results and the character isn't decoded properly. This is using expat 1.95.4. Attached is a simple XML file which illustrates the problem. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-26 20:30 Message: Logged In: YES user_id=290026 Yes, this is a bug. utf8_isInvalid3 tries to detect the invalid XML sequences (*not* invalid unicode) EF BF BE and EF BF BF, but only checks the first and third byte, not the second one. Fix alread checked into CVS (xmltok.c 1.23). Please check out and test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 From noreply@sourceforge.net Tue Aug 27 17:15:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 09:15:36 -0700 Subject: [Expat-bugs] [ expat-Bugs-600479 ] error decoding UTF-8 triplet Message-ID: Bugs item #600479, was opened at 2002-08-26 14:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 Category: None Group: Test Required Status: Open Resolution: Fixed Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: error decoding UTF-8 triplet Initial Comment: On Windows, when reading the UTF-8 sequence "EF BA BF", utf8_isInvalid3 returns TRUE, when it should return FALSE. This UTF-8 sequence encodes to "FEBF" as UCS-2 (Unicode), but as a result of utf8_isInvalid3 returning TRUE, an error results and the character isn't decoded properly. This is using expat 1.95.4. Attached is a simple XML file which illustrates the problem. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 09:15 Message: Logged In: NO Thanks Karl. I applied your fix to the define UTF8_INVALID3 with the expat 1.95.4 tarball (xmltok.c) and this worked fine, however, when I tried using what was in CVS, everything blew up on me. I can pass you some further test cases and possibly some patches, if you like. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-26 17:30 Message: Logged In: YES user_id=290026 Yes, this is a bug. utf8_isInvalid3 tries to detect the invalid XML sequences (*not* invalid unicode) EF BF BE and EF BF BF, but only checks the first and third byte, not the second one. Fix alread checked into CVS (xmltok.c 1.23). Please check out and test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 From noreply@sourceforge.net Tue Aug 27 17:19:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 09:19:25 -0700 Subject: [Expat-bugs] [ expat-Bugs-600479 ] error decoding UTF-8 triplet Message-ID: Bugs item #600479, was opened at 2002-08-26 17:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 Category: None Group: Test Required Status: Open Resolution: Fixed Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: error decoding UTF-8 triplet Initial Comment: On Windows, when reading the UTF-8 sequence "EF BA BF", utf8_isInvalid3 returns TRUE, when it should return FALSE. This UTF-8 sequence encodes to "FEBF" as UCS-2 (Unicode), but as a result of utf8_isInvalid3 returning TRUE, an error results and the character isn't decoded properly. This is using expat 1.95.4. Attached is a simple XML file which illustrates the problem. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-27 12:19 Message: Logged In: YES user_id=290026 Yes, please give us test cases that blow everything. Only from mistakes we can learn ... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 12:15 Message: Logged In: NO Thanks Karl. I applied your fix to the define UTF8_INVALID3 with the expat 1.95.4 tarball (xmltok.c) and this worked fine, however, when I tried using what was in CVS, everything blew up on me. I can pass you some further test cases and possibly some patches, if you like. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-26 20:30 Message: Logged In: YES user_id=290026 Yes, this is a bug. utf8_isInvalid3 tries to detect the invalid XML sequences (*not* invalid unicode) EF BF BE and EF BF BF, but only checks the first and third byte, not the second one. Fix alread checked into CVS (xmltok.c 1.23). Please check out and test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 From noreply@sourceforge.net Tue Aug 27 17:29:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 09:29:05 -0700 Subject: [Expat-bugs] [ expat-Bugs-600479 ] error decoding UTF-8 triplet Message-ID: Bugs item #600479, was opened at 2002-08-26 17:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 Category: None Group: Test Required Status: Open Resolution: Fixed Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: error decoding UTF-8 triplet Initial Comment: On Windows, when reading the UTF-8 sequence "EF BA BF", utf8_isInvalid3 returns TRUE, when it should return FALSE. This UTF-8 sequence encodes to "FEBF" as UCS-2 (Unicode), but as a result of utf8_isInvalid3 returning TRUE, an error results and the character isn't decoded properly. This is using expat 1.95.4. Attached is a simple XML file which illustrates the problem. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-27 12:29 Message: Logged In: YES user_id=3066 I've got a test case ready to checkin for the specific reported character that caused problems in the original report, but will hold off checking it in until we have the additional failure information, so I can generalize the test. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-27 12:19 Message: Logged In: YES user_id=290026 Yes, please give us test cases that blow everything. Only from mistakes we can learn ... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 12:15 Message: Logged In: NO Thanks Karl. I applied your fix to the define UTF8_INVALID3 with the expat 1.95.4 tarball (xmltok.c) and this worked fine, however, when I tried using what was in CVS, everything blew up on me. I can pass you some further test cases and possibly some patches, if you like. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-26 20:30 Message: Logged In: YES user_id=290026 Yes, this is a bug. utf8_isInvalid3 tries to detect the invalid XML sequences (*not* invalid unicode) EF BF BE and EF BF BF, but only checks the first and third byte, not the second one. Fix alread checked into CVS (xmltok.c 1.23). Please check out and test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 From noreply@sourceforge.net Tue Aug 27 17:59:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 09:59:50 -0700 Subject: [Expat-bugs] [ expat-Bugs-600479 ] error decoding UTF-8 triplet Message-ID: Bugs item #600479, was opened at 2002-08-26 14:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 Category: None Group: Test Required Status: Open Resolution: Fixed Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: error decoding UTF-8 triplet Initial Comment: On Windows, when reading the UTF-8 sequence "EF BA BF", utf8_isInvalid3 returns TRUE, when it should return FALSE. This UTF-8 sequence encodes to "FEBF" as UCS-2 (Unicode), but as a result of utf8_isInvalid3 returning TRUE, an error results and the character isn't decoded properly. This is using expat 1.95.4. Attached is a simple XML file which illustrates the problem. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 09:59 Message: Logged In: NO Sorry, I should be more specific: the problems I am having with the source from CVS do not relate specifically to UTF-8 encodings, but lots of different problems like segmentation violations, etcetera. These problems did not occur with 1.95.4, except the UTF-8 problem. I will isolate the specifics for you over the next couple of days. I haven't been using any new functionality. The code I have is using the 1.95.2 API. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-27 09:29 Message: Logged In: YES user_id=3066 I've got a test case ready to checkin for the specific reported character that caused problems in the original report, but will hold off checking it in until we have the additional failure information, so I can generalize the test. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-27 09:19 Message: Logged In: YES user_id=290026 Yes, please give us test cases that blow everything. Only from mistakes we can learn ... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 09:15 Message: Logged In: NO Thanks Karl. I applied your fix to the define UTF8_INVALID3 with the expat 1.95.4 tarball (xmltok.c) and this worked fine, however, when I tried using what was in CVS, everything blew up on me. I can pass you some further test cases and possibly some patches, if you like. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-26 17:30 Message: Logged In: YES user_id=290026 Yes, this is a bug. utf8_isInvalid3 tries to detect the invalid XML sequences (*not* invalid unicode) EF BF BE and EF BF BF, but only checks the first and third byte, not the second one. Fix alread checked into CVS (xmltok.c 1.23). Please check out and test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 From noreply@sourceforge.net Tue Aug 27 18:01:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 10:01:28 -0700 Subject: [Expat-bugs] [ expat-Bugs-600479 ] error decoding UTF-8 triplet Message-ID: Bugs item #600479, was opened at 2002-08-26 14:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 Category: None Group: Test Required Status: Open Resolution: Fixed Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: error decoding UTF-8 triplet Initial Comment: On Windows, when reading the UTF-8 sequence "EF BA BF", utf8_isInvalid3 returns TRUE, when it should return FALSE. This UTF-8 sequence encodes to "FEBF" as UCS-2 (Unicode), but as a result of utf8_isInvalid3 returning TRUE, an error results and the character isn't decoded properly. This is using expat 1.95.4. Attached is a simple XML file which illustrates the problem. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 10:01 Message: Logged In: NO Sorry, I should be more specific: the problems I am having with the source from CVS do not relate specifically to UTF-8 encodings, but lots of different problems like segmentation violations, etcetera. These problems did not occur with 1.95.4, except the UTF-8 problem. I will isolate the specifics for you over the next couple of days. I haven't been using any new functionality. The code I have is using the 1.95.2 API. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 09:59 Message: Logged In: NO Sorry, I should be more specific: the problems I am having with the source from CVS do not relate specifically to UTF-8 encodings, but lots of different problems like segmentation violations, etcetera. These problems did not occur with 1.95.4, except the UTF-8 problem. I will isolate the specifics for you over the next couple of days. I haven't been using any new functionality. The code I have is using the 1.95.2 API. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-27 09:29 Message: Logged In: YES user_id=3066 I've got a test case ready to checkin for the specific reported character that caused problems in the original report, but will hold off checking it in until we have the additional failure information, so I can generalize the test. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-27 09:19 Message: Logged In: YES user_id=290026 Yes, please give us test cases that blow everything. Only from mistakes we can learn ... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 09:15 Message: Logged In: NO Thanks Karl. I applied your fix to the define UTF8_INVALID3 with the expat 1.95.4 tarball (xmltok.c) and this worked fine, however, when I tried using what was in CVS, everything blew up on me. I can pass you some further test cases and possibly some patches, if you like. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-26 17:30 Message: Logged In: YES user_id=290026 Yes, this is a bug. utf8_isInvalid3 tries to detect the invalid XML sequences (*not* invalid unicode) EF BF BE and EF BF BF, but only checks the first and third byte, not the second one. Fix alread checked into CVS (xmltok.c 1.23). Please check out and test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 From noreply@sourceforge.net Tue Aug 27 18:04:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 10:04:45 -0700 Subject: [Expat-bugs] [ expat-Bugs-600479 ] error decoding UTF-8 triplet Message-ID: Bugs item #600479, was opened at 2002-08-26 17:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 Category: None Group: Test Required Status: Open Resolution: Fixed Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: error decoding UTF-8 triplet Initial Comment: On Windows, when reading the UTF-8 sequence "EF BA BF", utf8_isInvalid3 returns TRUE, when it should return FALSE. This UTF-8 sequence encodes to "FEBF" as UCS-2 (Unicode), but as a result of utf8_isInvalid3 returning TRUE, an error results and the character isn't decoded properly. This is using expat 1.95.4. Attached is a simple XML file which illustrates the problem. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-27 13:04 Message: Logged In: YES user_id=290026 Maybe you checked out from CVS in between changes we made. Could you please re-try with the newest? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 13:01 Message: Logged In: NO Sorry, I should be more specific: the problems I am having with the source from CVS do not relate specifically to UTF-8 encodings, but lots of different problems like segmentation violations, etcetera. These problems did not occur with 1.95.4, except the UTF-8 problem. I will isolate the specifics for you over the next couple of days. I haven't been using any new functionality. The code I have is using the 1.95.2 API. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 12:59 Message: Logged In: NO Sorry, I should be more specific: the problems I am having with the source from CVS do not relate specifically to UTF-8 encodings, but lots of different problems like segmentation violations, etcetera. These problems did not occur with 1.95.4, except the UTF-8 problem. I will isolate the specifics for you over the next couple of days. I haven't been using any new functionality. The code I have is using the 1.95.2 API. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-27 12:29 Message: Logged In: YES user_id=3066 I've got a test case ready to checkin for the specific reported character that caused problems in the original report, but will hold off checking it in until we have the additional failure information, so I can generalize the test. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-27 12:19 Message: Logged In: YES user_id=290026 Yes, please give us test cases that blow everything. Only from mistakes we can learn ... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 12:15 Message: Logged In: NO Thanks Karl. I applied your fix to the define UTF8_INVALID3 with the expat 1.95.4 tarball (xmltok.c) and this worked fine, however, when I tried using what was in CVS, everything blew up on me. I can pass you some further test cases and possibly some patches, if you like. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-26 20:30 Message: Logged In: YES user_id=290026 Yes, this is a bug. utf8_isInvalid3 tries to detect the invalid XML sequences (*not* invalid unicode) EF BF BE and EF BF BF, but only checks the first and third byte, not the second one. Fix alread checked into CVS (xmltok.c 1.23). Please check out and test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 From noreply@sourceforge.net Tue Aug 27 18:07:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 10:07:29 -0700 Subject: [Expat-bugs] [ expat-Bugs-600479 ] error decoding UTF-8 triplet Message-ID: Bugs item #600479, was opened at 2002-08-26 17:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 Category: None Group: Test Required >Status: Closed Resolution: Fixed Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: error decoding UTF-8 triplet Initial Comment: On Windows, when reading the UTF-8 sequence "EF BA BF", utf8_isInvalid3 returns TRUE, when it should return FALSE. This UTF-8 sequence encodes to "FEBF" as UCS-2 (Unicode), but as a result of utf8_isInvalid3 returning TRUE, an error results and the character isn't decoded properly. This is using expat 1.95.4. Attached is a simple XML file which illustrates the problem. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-27 13:07 Message: Logged In: YES user_id=3066 Ok, I've commited the regression test for this as tests/runtests.c revision 1.34. The other bugs should be filed in new reports. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-27 13:04 Message: Logged In: YES user_id=290026 Maybe you checked out from CVS in between changes we made. Could you please re-try with the newest? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 13:01 Message: Logged In: NO Sorry, I should be more specific: the problems I am having with the source from CVS do not relate specifically to UTF-8 encodings, but lots of different problems like segmentation violations, etcetera. These problems did not occur with 1.95.4, except the UTF-8 problem. I will isolate the specifics for you over the next couple of days. I haven't been using any new functionality. The code I have is using the 1.95.2 API. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 12:59 Message: Logged In: NO Sorry, I should be more specific: the problems I am having with the source from CVS do not relate specifically to UTF-8 encodings, but lots of different problems like segmentation violations, etcetera. These problems did not occur with 1.95.4, except the UTF-8 problem. I will isolate the specifics for you over the next couple of days. I haven't been using any new functionality. The code I have is using the 1.95.2 API. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-27 12:29 Message: Logged In: YES user_id=3066 I've got a test case ready to checkin for the specific reported character that caused problems in the original report, but will hold off checking it in until we have the additional failure information, so I can generalize the test. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-27 12:19 Message: Logged In: YES user_id=290026 Yes, please give us test cases that blow everything. Only from mistakes we can learn ... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 12:15 Message: Logged In: NO Thanks Karl. I applied your fix to the define UTF8_INVALID3 with the expat 1.95.4 tarball (xmltok.c) and this worked fine, however, when I tried using what was in CVS, everything blew up on me. I can pass you some further test cases and possibly some patches, if you like. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-26 20:30 Message: Logged In: YES user_id=290026 Yes, this is a bug. utf8_isInvalid3 tries to detect the invalid XML sequences (*not* invalid unicode) EF BF BE and EF BF BF, but only checks the first and third byte, not the second one. Fix alread checked into CVS (xmltok.c 1.23). Please check out and test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600479&group_id=10127 From noreply@sourceforge.net Tue Aug 27 21:04:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 13:04:51 -0700 Subject: [Expat-bugs] [ expat-Patches-600964 ] Element name storage optimization Message-ID: Patches item #600964, was opened at 2002-08-27 16:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=600964&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Element name storage optimization Initial Comment: Expat stores an element's "raw name" (=unconverted) as well as its encoded form. Storage of the raw name can be optimized by having the tag->rawName member point directly into the parse buffer. However, this currently is only done for the last buffer chunk, since previous parse buffers are discarded. So, most of the time raw names are stored in a designated buffer, causing expensive memory allocations. One can optimize this by only storing those raw names in a separate buffer whose elements are still open when the parse buffer is about to be discarded. In other words, the raw names of elements that are opened *and* closed while the same buffer is parsed are never stored, since the life time of their raw names is shorter than the life time of the parse buffer. The attached patch (xmlparse.c.diff) tries to achieve that. Performance benefits should be most noticeable for large XML documents that are not deeply nested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=600964&group_id=10127 From tim.crook@adobe.com Tue Aug 27 21:11:15 2002 From: tim.crook@adobe.com (Tim Crook) Date: Tue, 27 Aug 2002 16:11:15 -0400 Subject: [Expat-bugs] Problem with current expat in CVS and XML_ParserCreate_MM Message-ID: <311000B0752ED211B61700805F0D6B0902FDC367@ottmail3.jetform.com> Hi Karl and Fred. I see problems in XML_ParserCreate_MM when parserInit is called before poolInit initializes tempPool. poolCopyString is called using the uninitialized variable tempPool, which causes unpredictable results, in my case, an access violation. Shouldn't poolInit be called before parserInit? Here is an updated version of XML_ParserCreate_MM, which calls poolInit first. XML_Parser XML_ParserCreate_MM(const XML_Char *encodingName, const XML_Memory_Handling_Suite *memsuite, const XML_Char *nameSep) { XML_Parser parser; static const XML_Char implicitContext[] = { 'x', 'm', 'l', '=', 'h', 't', 't', 'p', ':', '/', '/', 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', 'X', 'M', 'L', '/', '1', '9', '9', '8', '/', 'n', 'a', 'm', 'e', 's', 'p', 'a', 'c', 'e', '\0' }; if (memsuite) { XML_Memory_Handling_Suite *mtemp; parser = memsuite->malloc_fcn(sizeof(struct XML_ParserStruct)); if (parser != NULL) { mtemp = &(parser->m_mem); mtemp->malloc_fcn = memsuite->malloc_fcn; mtemp->realloc_fcn = memsuite->realloc_fcn; mtemp->free_fcn = memsuite->free_fcn; } } else { XML_Memory_Handling_Suite *mtemp; parser = malloc(sizeof(struct XML_ParserStruct)); if (parser != NULL) { mtemp = &(parser->m_mem); mtemp->malloc_fcn = malloc; mtemp->realloc_fcn = realloc; mtemp->free_fcn = free; } } if (!parser) return parser; buffer = NULL; bufferLim = NULL; attsSize = INIT_ATTS_SIZE; atts = MALLOC(attsSize * sizeof(ATTRIBUTE)); if (atts == NULL) { FREE(parser); return NULL; } dataBuf = MALLOC(INIT_DATA_BUF_SIZE * sizeof(XML_Char)); if (dataBuf == NULL) { FREE(atts); FREE(parser); return NULL; } dataBufEnd = dataBuf + INIT_DATA_BUF_SIZE; freeBindingList = NULL; freeTagList = NULL; groupSize = 0; groupConnector = NULL; unknownEncodingHandler = NULL; unknownEncodingHandlerData = NULL; namespaceSeparator = '!'; ns = XML_FALSE; ns_triplets = XML_FALSE; poolInit(&tempPool, &(parser->m_mem)); poolInit(&temp2Pool, &(parser->m_mem)); parserInit(parser, encodingName); dtdInit(&dtd, parser); if (!atts || !dataBuf || (encodingName && !protocolEncodingName)) { XML_ParserFree(parser); return NULL; } if (nameSep) { ns = XML_TRUE; internalEncoding = XmlGetInternalEncodingNS(); namespaceSeparator = *nameSep; if (!setContext(parser, implicitContext)) { XML_ParserFree(parser); return NULL; } } else { internalEncoding = XmlGetInternalEncoding(); } return parser; } _________________________________________ Tim Crook Computer Scientist Adobe Systems Canada Inc. > 785 Carling Avenue > Ottawa, Ontario > Canada K1S 5H4 > Phone: +1 613.751.4800 Ext 5734 Fax: +1 613.594.8886 E-mail: tim.crook@adobe.com From noreply@sourceforge.net Tue Aug 27 21:15:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 13:15:36 -0700 Subject: [Expat-bugs] [ expat-Patches-600964 ] Element name storage optimization Message-ID: Patches item #600964, was opened at 2002-08-27 16:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=600964&group_id=10127 Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Karl Waclawek (kwaclaw) >Assigned to: Karl Waclawek (kwaclaw) Summary: Element name storage optimization Initial Comment: Expat stores an element's "raw name" (=unconverted) as well as its encoded form. Storage of the raw name can be optimized by having the tag->rawName member point directly into the parse buffer. However, this currently is only done for the last buffer chunk, since previous parse buffers are discarded. So, most of the time raw names are stored in a designated buffer, causing expensive memory allocations. One can optimize this by only storing those raw names in a separate buffer whose elements are still open when the parse buffer is about to be discarded. In other words, the raw names of elements that are opened *and* closed while the same buffer is parsed are never stored, since the life time of their raw names is shorter than the life time of the parse buffer. The attached patch (xmlparse.c.diff) tries to achieve that. Performance benefits should be most noticeable for large XML documents that are not deeply nested. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-27 16:15 Message: Logged In: YES user_id=3066 Works for me -- no objections to checking it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=600964&group_id=10127 From fdrake@acm.org Tue Aug 27 21:19:54 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 27 Aug 2002 16:19:54 -0400 Subject: [Expat-bugs] Problem with current expat in CVS and XML_ParserCreate_MM In-Reply-To: <311000B0752ED211B61700805F0D6B0902FDC367@ottmail3.jetform.com> References: <311000B0752ED211B61700805F0D6B0902FDC367@ottmail3.jetform.com> Message-ID: <15723.57066.825907.471139@grendel.zope.com> Tim Crook writes: > I see problems in XML_ParserCreate_MM when parserInit is called before > poolInit initializes tempPool. poolCopyString is called using the > uninitialized variable tempPool, which causes unpredictable results, in my > case, an access violation. Shouldn't poolInit be called before parserInit? I think you're right! Do you mind telling us what platform you're using that gets a segfault on this? This is the first report of this we've had that I'm aware of. I'll commit this change now. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From noreply@sourceforge.net Tue Aug 27 21:26:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 13:26:07 -0700 Subject: [Expat-bugs] [ expat-Patches-599715 ] Enable undeclared DTD Message-ID: Patches item #599715, was opened at 2002-08-24 14:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=599715&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Enable undeclared DTD Initial Comment: SAX2 provides the ability to use a customer provided external DTD when there is no external subset. Check out the definition of getExternalSubset on this page: http://sax.sourceforge.net/apidoc/org/xml/sax/ext/Entity Resolver2.html I patched Expat to enable such behaviour. When the user calls the new API function XML_UseForeignDTD() with an argument of XML_TRUE, then the externalEntityRefHandler will be called even if there is no external subset/DTD declared. In such a case the systemId argument will be NULL. A "foreign DTD" would be interpreted just as if the document had an external subset reference, that is, the internal field dtd.hasParamEntityRefs would become true. Patch attached. This patch also includes additional improvements/fixes that became apparent when working on the patch. These affect the function dtdReset() and the notStandaloneHandler(). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-27 16:26 Message: Logged In: YES user_id=3066 Isn't this already checked in? Please close it when you're done. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-25 16:28 Message: Logged In: YES user_id=290026 I added the macro #define parsing (processor != prologInitProcessor) which returns true once XML_Parse or XML_ParseBuffer has been called. This is used to block setting of the useForeignDTD flag when parsing is under way. I have also applied this logic to these other functions: XML_SetEncoding XML_SetParamEntityParsing XML_SetReturnNSTriplets Since there is a chance that parser logic might get upset if the corresponding flags are changed after parsing has begun. New patch version attached with description "Patch with safety feature added". ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-24 19:28 Message: Logged In: YES user_id=290026 Made small improvement to patch. Thinking about changing the API from XML_UseForeignDTD(parser, useDTD) to XML_SetUseForeignDTDHandler(parser, callback). The value of the internal field useForeignDTD is used only once, but updated multiple times. With the orginal API the caller has write access to this field and can potentially mess up the logic, with the new one, the parser reads it when it needs it, and then has full control. Comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=599715&group_id=10127 From noreply@sourceforge.net Tue Aug 27 21:26:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 13:26:29 -0700 Subject: [Expat-bugs] [ expat-Bugs-600971 ] XML_ParserCreate_MM and expat 1.95.5 Message-ID: Bugs item #600971, was opened at 2002-08-27 13:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600971&group_id=10127 Category: www.libexpat.org Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: XML_ParserCreate_MM and expat 1.95.5 Initial Comment: This is a problem with the current CVS version of expat. I see problems in XML_ParserCreate_MM when parserInit is called before poolInit initializes tempPool. In parseInit, poolCopyString is called using the uninitialized variable tempPool, which causes unpredictable results, in my case, an access violation. Shouldn't poolInit be called before parserInit? Attached is an updated version of XML_ParserCreate_MM, which calls poolInit first. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600971&group_id=10127 From noreply@sourceforge.net Tue Aug 27 21:32:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 13:32:15 -0700 Subject: [Expat-bugs] [ expat-Bugs-587211 ] make error Message-ID: Bugs item #587211, was opened at 2002-07-26 15:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=587211&group_id=10127 Category: None Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: make error Initial Comment: seaport:/tmp/expat-1.95.4# make /usr/bin/bash ./libtool --silent --mode=link gcc -g -O2 - Wall -Wmissing-prototypes -Wstrict-prototypes -I./lib - I. -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/unixfilemap.o libexpat.la xmlwf/xmlfile.o: Undefined symbol `_open' referenced (use -lc ?) xmlwf/xmlfile.o: Undefined symbol `_close' referenced (use -lc ?) xmlwf/xmlfile.o: Undefined symbol `_read' referenced (use -lc ?) xmlwf/unixfilemap.o: Undefined symbol `_open' referenced (use -lc ?) xmlwf/unixfilemap.o: Undefined symbol `_fstat' referenced (use -lc ?) xmlwf/unixfilemap.o: Undefined symbol `_close' referenced (use -lc ?) xmlwf/unixfilemap.o: Undefined symbol `_munmap' referenced (use -lc ?) ld: Spurious undefined symbols: # undefined symbols 5, reported 0 *** Error code 1 Stop. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-27 16:32 Message: Logged In: YES user_id=3066 I think we fixed this in xmlwf/unixfilemap.c 1.7, which has been included since Expat 1.95.3. Will the submitter please try revision 1.95.4 and update the report? Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-04 20:47 Message: Logged In: YES user_id=33168 If you add -lc to the link line between xmlwf/unixfilemap.o & libexpat.la, does it work? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-07-26 16:49 Message: Logged In: YES user_id=290026 Fred, maybe you can help. ---------------------------------------------------------------------- Comment By: Dave Reinhardt (thepair) Date: 2002-07-26 16:43 Message: Logged In: YES user_id=53868 seaport:/tmp/expat-1.95.0# which gcc /nfs/usr/bin/gcc seaport:/tmp/expat-1.95.0# gcc -v gcc version 2.7.2.1 ---------------------------------------------------------------------- Comment By: Dave Reinhardt (thepair) Date: 2002-07-26 16:40 Message: Logged In: YES user_id=53868 What OS/platform? Which version of it? PowerBSD Virtual Operating System v2.1 ELF-RELEASE (216.94.9.250) (ttyp0) PowerBSD v2.0-BETA - Copyright (c) 1997, 1998 Innosolve Systems Inc. What compiler version? can you tell from the output of the ./config command? loading cache ./config.cache checking host system type... i386-unknown-freebsd3.0 checking build system type... i386-unknown-freebsd3.0 checking for ranlib... (cached) ranlib checking for gcc... (cached) gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross- compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for ld used by GCC... (cached) /usr/libexec/aout/ld checking if the linker (/usr/libexec/aout/ld) is GNU ld... (cached) no checking for BSD-compatible nm... (cached) /nfs/usr/bin/nm - p checking whether ln -s works... (cached) yes updating cache ./config.cache loading cache ./config.cache within ltconfig checking for object suffix... o checking for executable suffix... (cached) no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.lo... yes checking if gcc supports -fno-rtti -fno-exceptions ... no checking if gcc static flag -static works... -static checking if the linker (/usr/libexec/aout/ld) is GNU ld... no checking whether the linker (/usr/libexec/aout/ld) supports shared libraries... yes checking command to parse /nfs/usr/bin/nm -p output... ok checking how to hardcode library paths into programs... immediate checking for /usr/libexec/aout/ld option to reload object files... -r checking dynamic linker characteristics... freebsd3.0 ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for objdir... .libs creating libtool updating cache ./config.cache loading cache ./config.cache checking for gcc... (cached) gcc checking whether the C compiler (gcc -g -O2 ) works... yes checking whether the C compiler (gcc -g -O2 ) is a cross- compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for a BSD compatible install... (cached) /nfs/usr/bin/install -c checking how to run the C preprocessor... (cached) gcc -E checking for ANSI C header files... (cached) yes checking for fcntl.h... (cached) yes checking for unistd.h... (cached) yes checking whether byte ordering is bigendian... (cached) no checking for working const... (cached) yes checking for off_t... (cached) yes checking for size_t... (cached) yes checking for 8-bit clean memcmp... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... (cached) yes checking for working mmap... (cached) yes checking for memmove... (cached) yes checking for bcopy... (cached) yes updating cache ./config.cache creating ./config.status creating Makefile creating lib/Makefile creating xmlwf/Makefile creating examples/Makefile creating config.h config.h is unchanged make cd lib; make /bin/sh ../libtool --mode=link gcc -version-info 0:0:0 -g -O2 -o libexpat.la -rpath /usr/local/lib xmlparse.lo xmltok.lo xmlrole.lo rm -fr .libs/libexpat.la .libs/libexpat.* .libs/libexpat.* (cd . && ln -s xmlparse.lo xmlparse.o) *** Error code 1 Stop. *** Error code 1 What configuration - any changes or default? default This is not assumed to be a bug. It is something about the way I am doing it or the fact that I do not have root access to the server. Only root to my virtual server. I have successfully installed others. etc., etc. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-07-26 16:07 Message: Logged In: YES user_id=290026 Everything we need to know to be able to reproduce your problem. Obviously it works for us, so where should we start? What OS/platform? Which version of it? What compiler version? What configuration - any changes or default? etc., etc. ---------------------------------------------------------------------- Comment By: Dave Reinhardt (thepair) Date: 2002-07-26 15:59 Message: Logged In: YES user_id=53868 what kind of additional info please ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-07-26 15:52 Message: Logged In: YES user_id=290026 Without more information we will need to close this report without action. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=587211&group_id=10127 From kwaclaw@thestar.ca Tue Aug 27 21:33:23 2002 From: kwaclaw@thestar.ca (Karl Waclawek) Date: Tue, 27 Aug 2002 16:33:23 -0400 Subject: [Expat-bugs] Problem with current expat in CVS andXML_ParserCreate_MM References: <311000B0752ED211B61700805F0D6B0902FDC367@ottmail3.jetform.com> Message-ID: <03ea01c24e08$fd1a9d80$9e539696@citkwaclaww2k> > I see problems in XML_ParserCreate_MM when parserInit is called before > poolInit initializes tempPool. poolCopyString is called using the > uninitialized variable tempPool, which causes unpredictable results, in my > case, an access violation. Shouldn't poolInit be called before parserInit? Good catch - fix already checked in. Karl Get to know us http://www.thestar.com - Canada's largest daily newspaper online http://www.toronto.com - All you need to know about T.O. http://www.workopolis.com - Canada's biggest job site http://www.torontostartv.com - Webcasting & Production http://www.newinhomes.com - Ontario's Largest New Home & Condo Website http://www.waymoresports.com - Canada's most comprehensive sports site http://www.tmgtv.ca - Torstar Media Group Television From noreply@sourceforge.net Tue Aug 27 21:35:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 13:35:34 -0700 Subject: [Expat-bugs] [ expat-Patches-599715 ] Enable undeclared DTD Message-ID: Patches item #599715, was opened at 2002-08-24 14:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=599715&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Enable undeclared DTD Initial Comment: SAX2 provides the ability to use a customer provided external DTD when there is no external subset. Check out the definition of getExternalSubset on this page: http://sax.sourceforge.net/apidoc/org/xml/sax/ext/Entity Resolver2.html I patched Expat to enable such behaviour. When the user calls the new API function XML_UseForeignDTD() with an argument of XML_TRUE, then the externalEntityRefHandler will be called even if there is no external subset/DTD declared. In such a case the systemId argument will be NULL. A "foreign DTD" would be interpreted just as if the document had an external subset reference, that is, the internal field dtd.hasParamEntityRefs would become true. Patch attached. This patch also includes additional improvements/fixes that became apparent when working on the patch. These affect the function dtdReset() and the notStandaloneHandler(). ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-27 16:35 Message: Logged In: YES user_id=290026 Checked in. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-27 16:26 Message: Logged In: YES user_id=3066 Isn't this already checked in? Please close it when you're done. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-25 16:28 Message: Logged In: YES user_id=290026 I added the macro #define parsing (processor != prologInitProcessor) which returns true once XML_Parse or XML_ParseBuffer has been called. This is used to block setting of the useForeignDTD flag when parsing is under way. I have also applied this logic to these other functions: XML_SetEncoding XML_SetParamEntityParsing XML_SetReturnNSTriplets Since there is a chance that parser logic might get upset if the corresponding flags are changed after parsing has begun. New patch version attached with description "Patch with safety feature added". ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-24 19:28 Message: Logged In: YES user_id=290026 Made small improvement to patch. Thinking about changing the API from XML_UseForeignDTD(parser, useDTD) to XML_SetUseForeignDTDHandler(parser, callback). The value of the internal field useForeignDTD is used only once, but updated multiple times. With the orginal API the caller has write access to this field and can potentially mess up the logic, with the new one, the parser reads it when it needs it, and then has full control. Comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=599715&group_id=10127 From noreply@sourceforge.net Tue Aug 27 21:37:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 13:37:59 -0700 Subject: [Expat-bugs] [ expat-Bugs-600971 ] XML_ParserCreate_MM and expat 1.95.5 Message-ID: Bugs item #600971, was opened at 2002-08-27 16:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600971&group_id=10127 >Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: XML_ParserCreate_MM and expat 1.95.5 Initial Comment: This is a problem with the current CVS version of expat. I see problems in XML_ParserCreate_MM when parserInit is called before poolInit initializes tempPool. In parseInit, poolCopyString is called using the uninitialized variable tempPool, which causes unpredictable results, in my case, an access violation. Shouldn't poolInit be called before parserInit? Attached is an updated version of XML_ParserCreate_MM, which calls poolInit first. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-27 16:37 Message: Logged In: YES user_id=3066 Fixed in lib/xmlparse.c revisions 1.75 and 1.76. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=600971&group_id=10127 From noreply@sourceforge.net Tue Aug 27 21:46:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 13:46:11 -0700 Subject: [Expat-bugs] [ expat-Patches-600964 ] Element name storage optimization Message-ID: Patches item #600964, was opened at 2002-08-27 16:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=600964&group_id=10127 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Element name storage optimization Initial Comment: Expat stores an element's "raw name" (=unconverted) as well as its encoded form. Storage of the raw name can be optimized by having the tag->rawName member point directly into the parse buffer. However, this currently is only done for the last buffer chunk, since previous parse buffers are discarded. So, most of the time raw names are stored in a designated buffer, causing expensive memory allocations. One can optimize this by only storing those raw names in a separate buffer whose elements are still open when the parse buffer is about to be discarded. In other words, the raw names of elements that are opened *and* closed while the same buffer is parsed are never stored, since the life time of their raw names is shorter than the life time of the parse buffer. The attached patch (xmlparse.c.diff) tries to achieve that. Performance benefits should be most noticeable for large XML documents that are not deeply nested. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-27 16:46 Message: Logged In: YES user_id=290026 OK, checked it in. Hope you didn't just run tests, but checked my code too. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-27 16:15 Message: Logged In: YES user_id=3066 Works for me -- no objections to checking it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=600964&group_id=10127 From noreply@sourceforge.net Tue Aug 27 21:46:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 13:46:35 -0700 Subject: [Expat-bugs] [ expat-Patches-600964 ] Element name storage optimization Message-ID: Patches item #600964, was opened at 2002-08-27 16:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=600964&group_id=10127 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Element name storage optimization Initial Comment: Expat stores an element's "raw name" (=unconverted) as well as its encoded form. Storage of the raw name can be optimized by having the tag->rawName member point directly into the parse buffer. However, this currently is only done for the last buffer chunk, since previous parse buffers are discarded. So, most of the time raw names are stored in a designated buffer, causing expensive memory allocations. One can optimize this by only storing those raw names in a separate buffer whose elements are still open when the parse buffer is about to be discarded. In other words, the raw names of elements that are opened *and* closed while the same buffer is parsed are never stored, since the life time of their raw names is shorter than the life time of the parse buffer. The attached patch (xmlparse.c.diff) tries to achieve that. Performance benefits should be most noticeable for large XML documents that are not deeply nested. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-27 16:46 Message: Logged In: YES user_id=290026 OK, checked it in. Hope you didn't just run tests, but checked my code too. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-27 16:15 Message: Logged In: YES user_id=3066 Works for me -- no objections to checking it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=600964&group_id=10127 From noreply@sourceforge.net Wed Aug 28 00:46:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 16:46:59 -0700 Subject: [Expat-bugs] [ expat-Bugs-488899 ] Bad pointer from characterData handler Message-ID: Bugs item #488899, was opened at 2001-12-04 09:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=488899&group_id=10127 Category: None >Group: Platform Specific >Status: Pending >Resolution: Remind Priority: 5 Submitted By: Paul Plummer (plummpj) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Bad pointer from characterData handler Initial Comment: Expat frequently returns bad data pointers to my handler for XML_SetCharacterDataHandler. I have expat V 1.95.2 installed on a SUN w Solaris 2.5.1. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-27 19:46 Message: Logged In: YES user_id=3066 I just tried this again using the CVS version of Expat and the test for a "bad pointer" disabled, and saw no ill effects. Please test with the CVS version of Expat if possible. Be sure to follow the instructions in the README to build the XML_UNICODE version of the library. I'll ignore this until you're able to confirm that there's still a problem in a more current version of Expat (with a strong preference for the CVS version). Following up to this report on SourceForge will add this back to my list. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 12:30 Message: Logged In: YES user_id=3066 Your test for a "bad pointer" in Element::copyData() looks strange to me, but there's definately something weird going on. I'll add it to my plate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=488899&group_id=10127 From noreply@sourceforge.net Thu Aug 29 18:04:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 29 Aug 2002 10:04:48 -0700 Subject: [Expat-bugs] [ expat-Bugs-601978 ] xmlwf should link statically to Expat Message-ID: Bugs item #601978, was opened at 2002-08-29 13: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! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=601978&group_id=10127 From noreply@sourceforge.net Thu Aug 29 18:10:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 29 Aug 2002 10:10:29 -0700 Subject: [Expat-bugs] [ expat-Bugs-601978 ] xmlwf should link statically to Expat Message-ID: Bugs item #601978, was opened at 2002-08-29 13: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: Karl Waclawek (kwaclaw) Date: 2002-08-29 13: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@sourceforge.net Thu Aug 29 18:56:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 29 Aug 2002 10:56:48 -0700 Subject: [Expat-bugs] [ expat-Bugs-596931 ] XML_ParseReset and memory leaks Message-ID: Bugs item #596931, was opened at 2002-08-18 20:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596931&group_id=10127 Category: None Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: XML_ParseReset and memory leaks Initial Comment: The problem: XML_ParseReset function does not reset the parser correctly, resulting in memory leaks. These leaks can be observed using the windows task manager while running the sample code below. Expat version: 1.95.4 Platform: win200 Sample Application: include #include "expat.h" char buffer[] = ""; void main() { XML_Parser parser = XML_ParserCreate(NULL); while ( true ) { int ret = XML_Parse( parser, buffer, strlen(buffer ), 1); if( ret == 0 ) { abort(); } ret = XML_ParserReset( parser, NULL ); if( ret == 0 ) { abort(); } } } ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-29 13:56 Message: Logged In: YES user_id=290026 Got one bug report back from Tim Brook, which was fixed directly in CVS (xmlparse.c 1.75, 1.76). Other than that the fix seems fine and this report seems ready to be closed. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-22 11:08 Message: Logged In: YES user_id=290026 Patch applied - seems OK since it passed all my tests as well as the W3C test suite (with results as expected, no change from release 1.95.4). Hopefully that will get more people to test it. It seems the user community at large will only really use and test full releases, and to a lesser degree CVS submissions. Leave it open for a while, since we may get some feedback. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-18 21:53 Message: Logged In: YES user_id=290026 Yes, this is a bug, as discussed on expat-discuss. I have attached a first patch - still to be tested. The problem was that dtdDestroy was not called in XML_ParserReset, since dtd.scaffold was NULL. Then, when dtdInit() was later called in parserInit, the pointers were overwritten - leading to memory leaks. This was a logic problem - the original reason for checking dtd.scaffold was to prevent double-destroying the dtd structure, but dtd.scaffold was only set when there was a content model. I changed this by introducing the new functions dtdReset() and hashTableClear(). There were other logic errors too, that would not show up in the test case given, but would have led to memory leaks in other situations: - freeBindingList and inheritedBindings were overwritten - tagStack and freeTagList were overwritten - groupSize and groupConnector were overwritten Other changes: - There is no reason to have dtdDestroy/dtdReset conditional on XML_DTD. - The unknownEncodingHandler(Data) is not reset anymore, since this is not really a dynamic handler anyway. - I also removed dtdInit() from parserInit() and it is now called separately. - The return type of XML_ParserReset was changed from int to XML_Bool. This should not be much of a problem, since it is binary compatible, and XML_ParserReset is new and not even documented yet. - A couple of minor code cleanups were performed too, not to confuse the reader. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=596931&group_id=10127 From fdrake@acm.org Fri Aug 30 20:33:49 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 30 Aug 2002 15:33:49 -0400 Subject: [Expat-bugs] Mailing list migration complete Message-ID: <15727.51357.361390.448843@grendel.zope.com> The mailing list migration is now complete. Only the lists at libexpat.org should be active. The archives of the lists from SourceForge have been integrated, so you only need to go to one place to find email related to Expat. If you have any problems with the lists, please don't hesitate to contact me. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From noreply@sourceforge.net Sat Aug 31 02:27:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Aug 2002 18:27:47 -0700 Subject: [Expat-bugs] [ expat-Bugs-602729 ] Seg fault (with UTF-16 input) Message-ID: Bugs item #602729, was opened at 2002-08-31 01:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=602729&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) Summary: Seg fault (with UTF-16 input) Initial Comment: It happend, that I stumbled over a expat bug, that expreß itself with a seg fault. This was reproducable for the maintainers, I mailed about, with XML data example provided by me. Thanks to Karl there is already a fix checked in and thanks to Fred there's already a regression test. The only reason for this bug report is, to be the starting point for the documentation of the case. rolf ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=602729&group_id=10127 From noreply@sourceforge.net Sat Aug 31 03:17:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Aug 2002 19:17:56 -0700 Subject: [Expat-bugs] [ expat-Bugs-602729 ] Seg fault (with UTF-16 input) Message-ID: Bugs item #602729, was opened at 2002-08-30 21:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=602729&group_id=10127 Category: None >Group: Test Required Status: Open >Resolution: Accepted Priority: 5 Submitted By: Rolf Ade (pointsman) >Assigned to: Karl Waclawek (kwaclaw) Summary: Seg fault (with UTF-16 input) Initial Comment: It happend, that I stumbled over a expat bug, that expreß itself with a seg fault. This was reproducable for the maintainers, I mailed about, with XML data example provided by me. Thanks to Karl there is already a fix checked in and thanks to Fred there's already a regression test. The only reason for this bug report is, to be the starting point for the documentation of the case. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-30 22:17 Message: Logged In: YES user_id=290026 Here is how what I think happens to cause the seg fault: The tokenizer ..._prologTok returns -XML_TOK_PROLOG_S when it detects a CR that is at the end of the buffer. This is supposed to indicate - IMO - that there might be an incomplete linebreak, i.e. a LF might be following the CR in the next buffer. doProlog handles this by ignoring the token, and leaving the buffer pointer the same without advancing it, like in this code snippet: ... if (tok <= 0) { if (nextPtr != 0 && tok != XML_TOK_INVALID) { *nextPtr = s; return XML_ERROR_NONE; } ... However, epilogProcessor tries to report it, because it might well be the very last token. Like this: ... case -XML_TOK_PROLOG_S: if (defaultHandler) { eventEndPtr = end; reportDefault(parser, encoding, s, end); } /* fall through */ case XML_TOK_NONE: if (nextPtr) *nextPtr = end; return XML_ERROR_NONE; ... Now, if the "end" pointer (which will be passed back to XML_ParseBuffer through nextPtr) points into the middle of a character, then bufferPtr (in XML_ParseBuffer) points there too. This will cause problems for XML_UpdatePosition, because its while loop is based on iterating over complete characters, therefore the end condition (ptr == end) will never be true, and it will continue accessing memory past the end pointer until a seg fault is triggered. I propose this patch (check the attached diff file): ... case -XML_TOK_PROLOG_S: if (defaultHandler) { eventEndPtr = next; reportDefault(parser, encoding, s, next); } if (nextPtr) *nextPtr = next; return XML_ERROR_NONE; case XML_TOK_NONE: if (nextPtr) *nextPtr = s; return XML_ERROR_NONE; ... In order to properly report the end of the CR token, I also had to patch xmltok_impl.c to update the nextTokPtr parameter in this case (-XML_TOK_PROLOG_S). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=602729&group_id=10127 From noreply@sourceforge.net Sat Aug 31 04:11:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Aug 2002 20:11:14 -0700 Subject: [Expat-bugs] [ expat-Bugs-602729 ] Seg fault (with UTF-16 input) Message-ID: Bugs item #602729, was opened at 2002-08-30 21:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=602729&group_id=10127 Category: None Group: Test Required >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Karl Waclawek (kwaclaw) Summary: Seg fault (with UTF-16 input) Initial Comment: It happend, that I stumbled over a expat bug, that expreß itself with a seg fault. This was reproducable for the maintainers, I mailed about, with XML data example provided by me. Thanks to Karl there is already a fix checked in and thanks to Fred there's already a regression test. The only reason for this bug report is, to be the starting point for the documentation of the case. rolf ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-30 23:11 Message: Logged In: YES user_id=3066 I checked in a regression test for this as tests/runtests.c 1.35. Karl commited his fix as lib/xmlparse.c 1.82 and lib/xmltok_impl.c 1.6. Closing the bug report as fixed. Rolf, if you think this doesn't fix the bug, feel free to follow up, and we can re-open if appropriate. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-30 22:17 Message: Logged In: YES user_id=290026 Here is how what I think happens to cause the seg fault: The tokenizer ..._prologTok returns -XML_TOK_PROLOG_S when it detects a CR that is at the end of the buffer. This is supposed to indicate - IMO - that there might be an incomplete linebreak, i.e. a LF might be following the CR in the next buffer. doProlog handles this by ignoring the token, and leaving the buffer pointer the same without advancing it, like in this code snippet: ... if (tok <= 0) { if (nextPtr != 0 && tok != XML_TOK_INVALID) { *nextPtr = s; return XML_ERROR_NONE; } ... However, epilogProcessor tries to report it, because it might well be the very last token. Like this: ... case -XML_TOK_PROLOG_S: if (defaultHandler) { eventEndPtr = end; reportDefault(parser, encoding, s, end); } /* fall through */ case XML_TOK_NONE: if (nextPtr) *nextPtr = end; return XML_ERROR_NONE; ... Now, if the "end" pointer (which will be passed back to XML_ParseBuffer through nextPtr) points into the middle of a character, then bufferPtr (in XML_ParseBuffer) points there too. This will cause problems for XML_UpdatePosition, because its while loop is based on iterating over complete characters, therefore the end condition (ptr == end) will never be true, and it will continue accessing memory past the end pointer until a seg fault is triggered. I propose this patch (check the attached diff file): ... case -XML_TOK_PROLOG_S: if (defaultHandler) { eventEndPtr = next; reportDefault(parser, encoding, s, next); } if (nextPtr) *nextPtr = next; return XML_ERROR_NONE; case XML_TOK_NONE: if (nextPtr) *nextPtr = s; return XML_ERROR_NONE; ... In order to properly report the end of the CR token, I also had to patch xmltok_impl.c to update the nextTokPtr parameter in this case (-XML_TOK_PROLOG_S). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=602729&group_id=10127 From noreply@sourceforge.net Sat Aug 31 14:26:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 31 Aug 2002 06:26:38 -0700 Subject: [Expat-bugs] [ expat-Bugs-591556 ] Solaris make error Message-ID: Bugs item #591556, was opened at 2002-08-06 07:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=591556&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) 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: Nobody/Anonymous (nobody) Date: 2002-08-31 06: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