From noreply at sourceforge.net Wed Dec 4 13:57:46 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Dec 2002 05:57:46 -0800 Subject: [Expat-bugs] [ expat-Bugs-615815 ] Can not build expat-1.95.5.tar.gz Message-ID: Bugs item #615815, was opened at 2002-09-28 08:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615815&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Guy Adani (guyad11) Assigned to: Greg Stein (gstein) Summary: Can not build expat-1.95.5.tar.gz Initial Comment: I have downloaded expat-1.95.5.tar.gz to my PC, which has cygwin installed. According to the docs, I can install like I am running on a UNIX machine : "Building under Win32 If you're using the GNU compiler under cygwin, follow the Unix directions in the next section. Otherwise if you have Microsoft's Developer Studio installed, then from Windows Explorer double- click on "expat.dsp" in the lib directory and build and install in the usual manner." After running configure, I run make and got the following error: "$ make /bin/bash ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing- prototypes - Wstrict-prototypes -fexceptions -I./lib -I. -no-undefined -version- info 4:0:4 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole. lo /usr/lib/libcygwin.a(libcmain.o)(.text+0x6a): undefined reference to `WinMain@16 ' collect2: ld returned 1 exit status make: *** [libexpat.la] Error 1 " What do I need to do to install ? Attached is the configure log file. Thanks, Guy Adani ---------------------------------------------------------------------- Comment By: Frerk Boltjes (boltjes) Date: 2002-12-04 13:57 Message: Logged In: YES user_id=662066 It seems, there is a bug in the configure script. To build a Cygwin DLL the '-shared' option has to be used. Change line 4765, 4767 and 4769 from $CC ..... to $CC -shared ..... and start './configure' and 'make' again. Now, everything should work fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615815&group_id=10127 From noreply at sourceforge.net Wed Dec 4 14:52:58 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Dec 2002 06:52:58 -0800 Subject: [Expat-bugs] [ expat-Bugs-615815 ] Can not build expat-1.95.5.tar.gz Message-ID: Bugs item #615815, was opened at 2002-09-28 04:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615815&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Guy Adani (guyad11) >Assigned to: Gerrit Haase (siebenschlaefer) Summary: Can not build expat-1.95.5.tar.gz Initial Comment: I have downloaded expat-1.95.5.tar.gz to my PC, which has cygwin installed. According to the docs, I can install like I am running on a UNIX machine : "Building under Win32 If you're using the GNU compiler under cygwin, follow the Unix directions in the next section. Otherwise if you have Microsoft's Developer Studio installed, then from Windows Explorer double- click on "expat.dsp" in the lib directory and build and install in the usual manner." After running configure, I run make and got the following error: "$ make /bin/bash ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing- prototypes - Wstrict-prototypes -fexceptions -I./lib -I. -no-undefined -version- info 4:0:4 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole. lo /usr/lib/libcygwin.a(libcmain.o)(.text+0x6a): undefined reference to `WinMain@16 ' collect2: ld returned 1 exit status make: *** [libexpat.la] Error 1 " What do I need to do to install ? Attached is the configure log file. Thanks, Guy Adani ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-04 09:52 Message: Logged In: YES user_id=3066 Assigned to the Cygwin expert. ---------------------------------------------------------------------- Comment By: Frerk Boltjes (boltjes) Date: 2002-12-04 08:57 Message: Logged In: YES user_id=662066 It seems, there is a bug in the configure script. To build a Cygwin DLL the '-shared' option has to be used. Change line 4765, 4767 and 4769 from $CC ..... to $CC -shared ..... and start './configure' and 'make' again. Now, everything should work fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615815&group_id=10127 From noreply at sourceforge.net Sat Dec 7 17:10:02 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Dec 2002 09:10:02 -0800 Subject: [Expat-bugs] [ expat-Bugs-615815 ] Can not build expat-1.95.5.tar.gz Message-ID: Bugs item #615815, was opened at 2002-09-28 10:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615815&group_id=10127 Category: Build control Group: Platform Specific Status: Open >Resolution: Postponed Priority: 5 Submitted By: Guy Adani (guyad11) Assigned to: Gerrit Haase (siebenschlaefer) Summary: Can not build expat-1.95.5.tar.gz Initial Comment: I have downloaded expat-1.95.5.tar.gz to my PC, which has cygwin installed. According to the docs, I can install like I am running on a UNIX machine : "Building under Win32 If you're using the GNU compiler under cygwin, follow the Unix directions in the next section. Otherwise if you have Microsoft's Developer Studio installed, then from Windows Explorer double- click on "expat.dsp" in the lib directory and build and install in the usual manner." After running configure, I run make and got the following error: "$ make /bin/bash ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing- prototypes - Wstrict-prototypes -fexceptions -I./lib -I. -no-undefined -version- info 4:0:4 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole. lo /usr/lib/libcygwin.a(libcmain.o)(.text+0x6a): undefined reference to `WinMain@16 ' collect2: ld returned 1 exit status make: *** [libexpat.la] Error 1 " What do I need to do to install ? Attached is the configure log file. Thanks, Guy Adani ---------------------------------------------------------------------- >Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-12-07 18:10 Message: Logged In: YES user_id=76037 Hello, The problem with Cygwin is, that we use the devel version of libtool because libtool 1.4 is really broken (for Cygwin needs). In the future, after libtool 1.5 or later is released and used all over the place there will be no more major problems like this. Since the libtool and other autotool scripts in the original expat source are built using libtool 1.4.x they don't do the right thing for the Cygwin development chain and therefore all the scripts need to be rebuild with the current Cygwin 'devel'-autotoolchain. That is (as you can see in the patch): autoupdate (cd conftools/; rm -f ltmain.sh ltconfig) aclocal -I conftools libtoolize --force --copy --automake aclocal -I conftools ltfiles=/usr/autotool/devel/share cp $ltfiles/aclocal/libtool.m4 conftools/libtool.m4 cp $ltfiles/libtool/missing \ $ltfiles/libtool/install-sh \ $ltfiles/libtool/mkinstalldirs \ conftools/ # Generate the autoconf header template (expat_config.h.in) and ./configure # ${AUTOHEADER:-autoheader} echo "Creating configure ..." ### do some work to toss config.cache? ${AUTOCONF:-autoconf} # toss this; it gets created by autoconf on some systems rm -rf autom4te*.cache # exit with the right value, so any calling script can continue exit 0 SOLUTION: ========= Get the soucre from any Cygwin mirror or my site: http://koeln.convey.de/cywgin/expat/expat-1.95.5-1-src.tar.bz2 There is a buildscript and a patch included which will prepare the source for building on Cygwin. Also available separately: http://koeln.convey.de/cywgin/expat/expat-1.95.5-1.sh http://koeln.convey.de/cywgin/expat/expat-1.95.5-1.patch HTH, Gerrit ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-04 15:52 Message: Logged In: YES user_id=3066 Assigned to the Cygwin expert. ---------------------------------------------------------------------- Comment By: Frerk Boltjes (boltjes) Date: 2002-12-04 14:57 Message: Logged In: YES user_id=662066 It seems, there is a bug in the configure script. To build a Cygwin DLL the '-shared' option has to be used. Change line 4765, 4767 and 4769 from $CC ..... to $CC -shared ..... and start './configure' and 'make' again. Now, everything should work fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615815&group_id=10127 From noreply at sourceforge.net Sat Dec 7 17:12:51 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Dec 2002 09:12:51 -0800 Subject: [Expat-bugs] [ expat-Bugs-621797 ] Expat 1.95-5 build failure under Cygwin Message-ID: Bugs item #621797, was opened at 2002-10-11 12:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=621797&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Postponed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Gerrit Haase (siebenschlaefer) Summary: Expat 1.95-5 build failure under Cygwin Initial Comment: Attempting to build expat 1.95-5 under cygwin fails with the following: "/usr/lib/libcygwin.a(libcmain.o)(.text+0x81): undefined reference to `WinMain@16'" Full info from configure & make robertm@CLEMFAR ~/expat-1.95.5 $ ./configure checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking for gcc... gcc checking for C compiler default output... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ld used by GCC... /usr/i686-pc-cygwin/bin/ld.exe checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes checking for /usr/i686-pc-cygwin/bin/ld.exe option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependant libraries... file_magic file format pei*-i386(.*architecture: i386)? checking command to parse /usr/bin/nm -B output... ok checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... no checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for gcc option to produce PIC... -DDLL_EXPORT checking if gcc PIC flag -DDLL_EXPORT works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.lo... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking whether the linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... Win32 ld.exe checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes creating libtool checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking whether byte ordering is bigendian... no 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 robertm@CLEMFAR ~/expat-1.95.5 $ make /bin/bash ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I./lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c /bin/bash ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I./lib -I. -o lib/xmltok.lo -c lib/xmltok.c /bin/bash ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I./lib -I. -o lib/xmlrole.lo -c lib/xmlrole.c /bin/bash ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I./lib -I. -no-undefined -version-info 4:0:4 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo /usr/lib/libcygwin.a(libcmain.o)(.text+0x81): undefined reference to `WinMain@16' collect2: ld returned 1 exit status make: *** [libexpat.la] Error 1 ---------------------------------------------------------------------- >Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-12-07 18:12 Message: Logged In: YES user_id=76037 Hello, The problem with Cygwin is, that we use the devel version of libtool because libtool 1.4 is really broken (for Cygwin needs). In the future, after libtool 1.5 or later is released and used all over the place there will be no more major problems like this. Since the libtool and other autotool scripts in the original expat source are built using libtool 1.4.x they don't do the right thing for the Cygwin development chain and therefore all the scripts need to be rebuild with the current Cygwin 'devel'-autotoolchain. That is (as you can see in the patch): autoupdate (cd conftools/; rm -f ltmain.sh ltconfig) aclocal -I conftools libtoolize --force --copy --automake aclocal -I conftools ltfiles=/usr/autotool/devel/share cp $ltfiles/aclocal/libtool.m4 conftools/libtool.m4 cp $ltfiles/libtool/missing \ $ltfiles/libtool/install-sh \ $ltfiles/libtool/mkinstalldirs \ conftools/ # Generate the autoconf header template (expat_config.h.in) and ./configure # ${AUTOHEADER:-autoheader} echo "Creating configure ..." ### do some work to toss config.cache? ${AUTOCONF:-autoconf} # toss this; it gets created by autoconf on some systems rm -rf autom4te*.cache # exit with the right value, so any calling script can continue exit 0 SOLUTION: ========= Get the soucre from any Cygwin mirror or my site: http://koeln.convey.de/cywgin/expat/expat-1.95.5-1-src.tar.bz2 There is a buildscript and a patch included which will prepare the source for building on Cygwin. Also available separately: http://koeln.convey.de/cywgin/expat/expat-1.95.5-1.sh http://koeln.convey.de/cywgin/expat/expat-1.95.5-1.patch HTH, Gerrit ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-11 15:10 Message: Logged In: YES user_id=3066 Re-assigned to the CygWin expert. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=621797&group_id=10127 From noreply at sourceforge.net Sat Dec 7 17:13:01 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Dec 2002 09:13:01 -0800 Subject: [Expat-bugs] [ expat-Bugs-615815 ] Can not build expat-1.95.5.tar.gz Message-ID: Bugs item #615815, was opened at 2002-09-28 10:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615815&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed Resolution: Postponed Priority: 5 Submitted By: Guy Adani (guyad11) Assigned to: Gerrit Haase (siebenschlaefer) Summary: Can not build expat-1.95.5.tar.gz Initial Comment: I have downloaded expat-1.95.5.tar.gz to my PC, which has cygwin installed. According to the docs, I can install like I am running on a UNIX machine : "Building under Win32 If you're using the GNU compiler under cygwin, follow the Unix directions in the next section. Otherwise if you have Microsoft's Developer Studio installed, then from Windows Explorer double- click on "expat.dsp" in the lib directory and build and install in the usual manner." After running configure, I run make and got the following error: "$ make /bin/bash ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing- prototypes - Wstrict-prototypes -fexceptions -I./lib -I. -no-undefined -version- info 4:0:4 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole. lo /usr/lib/libcygwin.a(libcmain.o)(.text+0x6a): undefined reference to `WinMain@16 ' collect2: ld returned 1 exit status make: *** [libexpat.la] Error 1 " What do I need to do to install ? Attached is the configure log file. Thanks, Guy Adani ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-12-07 18:10 Message: Logged In: YES user_id=76037 Hello, The problem with Cygwin is, that we use the devel version of libtool because libtool 1.4 is really broken (for Cygwin needs). In the future, after libtool 1.5 or later is released and used all over the place there will be no more major problems like this. Since the libtool and other autotool scripts in the original expat source are built using libtool 1.4.x they don't do the right thing for the Cygwin development chain and therefore all the scripts need to be rebuild with the current Cygwin 'devel'-autotoolchain. That is (as you can see in the patch): autoupdate (cd conftools/; rm -f ltmain.sh ltconfig) aclocal -I conftools libtoolize --force --copy --automake aclocal -I conftools ltfiles=/usr/autotool/devel/share cp $ltfiles/aclocal/libtool.m4 conftools/libtool.m4 cp $ltfiles/libtool/missing \ $ltfiles/libtool/install-sh \ $ltfiles/libtool/mkinstalldirs \ conftools/ # Generate the autoconf header template (expat_config.h.in) and ./configure # ${AUTOHEADER:-autoheader} echo "Creating configure ..." ### do some work to toss config.cache? ${AUTOCONF:-autoconf} # toss this; it gets created by autoconf on some systems rm -rf autom4te*.cache # exit with the right value, so any calling script can continue exit 0 SOLUTION: ========= Get the soucre from any Cygwin mirror or my site: http://koeln.convey.de/cywgin/expat/expat-1.95.5-1-src.tar.bz2 There is a buildscript and a patch included which will prepare the source for building on Cygwin. Also available separately: http://koeln.convey.de/cywgin/expat/expat-1.95.5-1.sh http://koeln.convey.de/cywgin/expat/expat-1.95.5-1.patch HTH, Gerrit ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-04 15:52 Message: Logged In: YES user_id=3066 Assigned to the Cygwin expert. ---------------------------------------------------------------------- Comment By: Frerk Boltjes (boltjes) Date: 2002-12-04 14:57 Message: Logged In: YES user_id=662066 It seems, there is a bug in the configure script. To build a Cygwin DLL the '-shared' option has to be used. Change line 4765, 4767 and 4769 from $CC ..... to $CC -shared ..... and start './configure' and 'make' again. Now, everything should work fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615815&group_id=10127 From noreply at sourceforge.net Tue Dec 10 17:16:16 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Tue Dec 10 20:16:20 2002 Subject: [Expat-bugs] [ expat-Bugs-651754 ] Feat req: get XML_Memory_Handling_Suite Message-ID: Bugs item #651754, was opened at 2002-12-11 04:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: Feat req: get XML_Memory_Handling_Suite Initial Comment: It is not a bug report, it is a feature request. What do you think of adding the function, that returns the pointer to XML_Memory_Handling_Suite for passed XML_Parser? It is necessary for me, I am developing an extension for Expat and I would like to use the same allocation/reallocation/free function as the current XML_Parser uses. Since XML_Parser struct defined inside .C-file, I can't get an access to XML_Memory_Handling_Suite struct for the parser. Please add this function, since it will be very simple. Sincerely, Artyom Bolgar. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 From noreply at sourceforge.net Tue Dec 10 18:24:41 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Tue Dec 10 21:24:46 2002 Subject: [Expat-bugs] [ expat-Bugs-651754 ] Feat req: get XML_Memory_Handling_Suite Message-ID: Bugs item #651754, was opened at 2002-12-10 20:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: Feat req: get XML_Memory_Handling_Suite Initial Comment: It is not a bug report, it is a feature request. What do you think of adding the function, that returns the pointer to XML_Memory_Handling_Suite for passed XML_Parser? It is necessary for me, I am developing an extension for Expat and I would like to use the same allocation/reallocation/free function as the current XML_Parser uses. Since XML_Parser struct defined inside .C-file, I can't get an access to XML_Memory_Handling_Suite struct for the parser. Please add this function, since it will be very simple. Sincerely, Artyom Bolgar. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-10 21:24 Message: Logged In: YES user_id=290026 Are you creating the parser using XML_ParserCreate? In that case - without supplying an external memory handler, Expat just uses the standard C runtime functions malloc, realloc and free. If you use XML_ParserCreate_MM however, then *you* are supplying the memory handler yourself. In both cases you don't need the requested function. Is your situation different from what I described? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 From noreply at sourceforge.net Tue Dec 10 18:28:25 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Tue Dec 10 21:28:30 2002 Subject: [Expat-bugs] [ expat-Bugs-651754 ] Function to get XML_Memory_Handling_Suite Message-ID: Bugs item #651754, was opened at 2002-12-10 20:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 Category: None >Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) >Summary: Function to get XML_Memory_Handling_Suite Initial Comment: It is not a bug report, it is a feature request. What do you think of adding the function, that returns the pointer to XML_Memory_Handling_Suite for passed XML_Parser? It is necessary for me, I am developing an extension for Expat and I would like to use the same allocation/reallocation/free function as the current XML_Parser uses. Since XML_Parser struct defined inside .C-file, I can't get an access to XML_Memory_Handling_Suite struct for the parser. Please add this function, since it will be very simple. Sincerely, Artyom Bolgar. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-10 21:24 Message: Logged In: YES user_id=290026 Are you creating the parser using XML_ParserCreate? In that case - without supplying an external memory handler, Expat just uses the standard C runtime functions malloc, realloc and free. If you use XML_ParserCreate_MM however, then *you* are supplying the memory handler yourself. In both cases you don't need the requested function. Is your situation different from what I described? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 From noreply at sourceforge.net Wed Dec 11 03:32:56 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Wed Dec 11 06:33:05 2002 Subject: [Expat-bugs] [ expat-Bugs-651754 ] Function to get XML_Memory_Handling_Suite Message-ID: Bugs item #651754, was opened at 2002-12-11 04:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: Function to get XML_Memory_Handling_Suite Initial Comment: It is not a bug report, it is a feature request. What do you think of adding the function, that returns the pointer to XML_Memory_Handling_Suite for passed XML_Parser? It is necessary for me, I am developing an extension for Expat and I would like to use the same allocation/reallocation/free function as the current XML_Parser uses. Since XML_Parser struct defined inside .C-file, I can't get an access to XML_Memory_Handling_Suite struct for the parser. Please add this function, since it will be very simple. Sincerely, Artyom Bolgar. ---------------------------------------------------------------------- >Comment By: Artyom Bolgar (artyom17) Date: 2002-12-11 14:32 Message: Logged In: YES user_id=657326 Of course, I know about this. But in my case, I use XML_Parser passed by user (and it is created by him), and I don't know how it was created, either by XML_ParserCreate_MM or not. That is why I requested this function. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 05:24 Message: Logged In: YES user_id=290026 Are you creating the parser using XML_ParserCreate? In that case - without supplying an external memory handler, Expat just uses the standard C runtime functions malloc, realloc and free. If you use XML_ParserCreate_MM however, then *you* are supplying the memory handler yourself. In both cases you don't need the requested function. Is your situation different from what I described? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 From noreply at sourceforge.net Wed Dec 11 04:40:43 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Wed Dec 11 07:40:49 2002 Subject: [Expat-bugs] [ expat-Bugs-651754 ] Function to get XML_Memory_Handling_Suite Message-ID: Bugs item #651754, was opened at 2002-12-10 20:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: Function to get XML_Memory_Handling_Suite Initial Comment: It is not a bug report, it is a feature request. What do you think of adding the function, that returns the pointer to XML_Memory_Handling_Suite for passed XML_Parser? It is necessary for me, I am developing an extension for Expat and I would like to use the same allocation/reallocation/free function as the current XML_Parser uses. Since XML_Parser struct defined inside .C-file, I can't get an access to XML_Memory_Handling_Suite struct for the parser. Please add this function, since it will be very simple. Sincerely, Artyom Bolgar. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-11 07:40 Message: Logged In: YES user_id=3066 Can you explain why you need the memory handler they've asked Expat to use? The requirements aren't clear, so more explanation of the use case should help. Thanks. ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-12-11 06:32 Message: Logged In: YES user_id=657326 Of course, I know about this. But in my case, I use XML_Parser passed by user (and it is created by him), and I don't know how it was created, either by XML_ParserCreate_MM or not. That is why I requested this function. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-10 21:24 Message: Logged In: YES user_id=290026 Are you creating the parser using XML_ParserCreate? In that case - without supplying an external memory handler, Expat just uses the standard C runtime functions malloc, realloc and free. If you use XML_ParserCreate_MM however, then *you* are supplying the memory handler yourself. In both cases you don't need the requested function. Is your situation different from what I described? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 From noreply at sourceforge.net Wed Dec 11 05:59:55 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Wed Dec 11 09:04:04 2002 Subject: [Expat-bugs] [ expat-Bugs-651754 ] Function to get XML_Memory_Handling_Suite Message-ID: Bugs item #651754, was opened at 2002-12-10 20:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: Function to get XML_Memory_Handling_Suite Initial Comment: It is not a bug report, it is a feature request. What do you think of adding the function, that returns the pointer to XML_Memory_Handling_Suite for passed XML_Parser? It is necessary for me, I am developing an extension for Expat and I would like to use the same allocation/reallocation/free function as the current XML_Parser uses. Since XML_Parser struct defined inside .C-file, I can't get an access to XML_Memory_Handling_Suite struct for the parser. Please add this function, since it will be very simple. Sincerely, Artyom Bolgar. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 08:59 Message: Logged In: YES user_id=290026 Once you set an element declaration handler you need to free the content model passed to the handler, so you will need to know the memory handler in use. It is just a rare case that the code that sets the handlers has no control over the code that creates the parser. But it is not too far fetched, so IMO that feature request makes some sense, unless I am overlooking the obvious. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-11 07:40 Message: Logged In: YES user_id=3066 Can you explain why you need the memory handler they've asked Expat to use? The requirements aren't clear, so more explanation of the use case should help. Thanks. ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-12-11 06:32 Message: Logged In: YES user_id=657326 Of course, I know about this. But in my case, I use XML_Parser passed by user (and it is created by him), and I don't know how it was created, either by XML_ParserCreate_MM or not. That is why I requested this function. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-10 21:24 Message: Logged In: YES user_id=290026 Are you creating the parser using XML_ParserCreate? In that case - without supplying an external memory handler, Expat just uses the standard C runtime functions malloc, realloc and free. If you use XML_ParserCreate_MM however, then *you* are supplying the memory handler yourself. In both cases you don't need the requested function. Is your situation different from what I described? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 From noreply at sourceforge.net Wed Dec 11 06:38:27 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Wed Dec 11 09:38:34 2002 Subject: [Expat-bugs] [ expat-Bugs-651754 ] Function to get XML_Memory_Handling_Suite Message-ID: Bugs item #651754, was opened at 2002-12-10 20:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: Function to get XML_Memory_Handling_Suite Initial Comment: It is not a bug report, it is a feature request. What do you think of adding the function, that returns the pointer to XML_Memory_Handling_Suite for passed XML_Parser? It is necessary for me, I am developing an extension for Expat and I would like to use the same allocation/reallocation/free function as the current XML_Parser uses. Since XML_Parser struct defined inside .C-file, I can't get an access to XML_Memory_Handling_Suite struct for the parser. Please add this function, since it will be very simple. Sincerely, Artyom Bolgar. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-11 09:38 Message: Logged In: YES user_id=3066 Karl: Artyom didn't say he was setting a handler on an XML_Parser object someone else passed him, nor did he say he wasn't. The only specific I see here is that he wants to use the same resource handlers as the parser; it's not clear that this is a real requirement. I'll follow up with a discussion on expat-discuss. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 08:59 Message: Logged In: YES user_id=290026 Once you set an element declaration handler you need to free the content model passed to the handler, so you will need to know the memory handler in use. It is just a rare case that the code that sets the handlers has no control over the code that creates the parser. But it is not too far fetched, so IMO that feature request makes some sense, unless I am overlooking the obvious. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-11 07:40 Message: Logged In: YES user_id=3066 Can you explain why you need the memory handler they've asked Expat to use? The requirements aren't clear, so more explanation of the use case should help. Thanks. ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-12-11 06:32 Message: Logged In: YES user_id=657326 Of course, I know about this. But in my case, I use XML_Parser passed by user (and it is created by him), and I don't know how it was created, either by XML_ParserCreate_MM or not. That is why I requested this function. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-10 21:24 Message: Logged In: YES user_id=290026 Are you creating the parser using XML_ParserCreate? In that case - without supplying an external memory handler, Expat just uses the standard C runtime functions malloc, realloc and free. If you use XML_ParserCreate_MM however, then *you* are supplying the memory handler yourself. In both cases you don't need the requested function. Is your situation different from what I described? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 From noreply at sourceforge.net Wed Dec 11 07:23:25 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Wed Dec 11 10:23:31 2002 Subject: [Expat-bugs] [ expat-Bugs-651754 ] Function to get XML_Memory_Handling_Suite Message-ID: Bugs item #651754, was opened at 2002-12-10 20:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: Function to get XML_Memory_Handling_Suite Initial Comment: It is not a bug report, it is a feature request. What do you think of adding the function, that returns the pointer to XML_Memory_Handling_Suite for passed XML_Parser? It is necessary for me, I am developing an extension for Expat and I would like to use the same allocation/reallocation/free function as the current XML_Parser uses. Since XML_Parser struct defined inside .C-file, I can't get an access to XML_Memory_Handling_Suite struct for the parser. Please add this function, since it will be very simple. Sincerely, Artyom Bolgar. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 10:23 Message: Logged In: YES user_id=290026 Fred: I know that, but I just pointed out an example where it would make sense. I have another reason too that has to do with writing wrappers/bindings for Expat, but I will mention it in a reply to your upcoming message on expat-discuss. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-11 09:38 Message: Logged In: YES user_id=3066 Karl: Artyom didn't say he was setting a handler on an XML_Parser object someone else passed him, nor did he say he wasn't. The only specific I see here is that he wants to use the same resource handlers as the parser; it's not clear that this is a real requirement. I'll follow up with a discussion on expat-discuss. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 08:59 Message: Logged In: YES user_id=290026 Once you set an element declaration handler you need to free the content model passed to the handler, so you will need to know the memory handler in use. It is just a rare case that the code that sets the handlers has no control over the code that creates the parser. But it is not too far fetched, so IMO that feature request makes some sense, unless I am overlooking the obvious. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-11 07:40 Message: Logged In: YES user_id=3066 Can you explain why you need the memory handler they've asked Expat to use? The requirements aren't clear, so more explanation of the use case should help. Thanks. ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-12-11 06:32 Message: Logged In: YES user_id=657326 Of course, I know about this. But in my case, I use XML_Parser passed by user (and it is created by him), and I don't know how it was created, either by XML_ParserCreate_MM or not. That is why I requested this function. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-10 21:24 Message: Logged In: YES user_id=290026 Are you creating the parser using XML_ParserCreate? In that case - without supplying an external memory handler, Expat just uses the standard C runtime functions malloc, realloc and free. If you use XML_ParserCreate_MM however, then *you* are supplying the memory handler yourself. In both cases you don't need the requested function. Is your situation different from what I described? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 From noreply at sourceforge.net Wed Dec 11 11:40:36 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Wed Dec 11 14:40:44 2002 Subject: [Expat-bugs] [ expat-Bugs-651754 ] Function to get XML_Memory_Handling_Suite Message-ID: Bugs item #651754, was opened at 2002-12-10 20:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: Function to get XML_Memory_Handling_Suite Initial Comment: It is not a bug report, it is a feature request. What do you think of adding the function, that returns the pointer to XML_Memory_Handling_Suite for passed XML_Parser? It is necessary for me, I am developing an extension for Expat and I would like to use the same allocation/reallocation/free function as the current XML_Parser uses. Since XML_Parser struct defined inside .C-file, I can't get an access to XML_Memory_Handling_Suite struct for the parser. Please add this function, since it will be very simple. Sincerely, Artyom Bolgar. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 14:40 Message: Logged In: YES user_id=290026 Attached is a potential patch MemSuite.diff. Includes changes to expat.h, xmlparse.c and the DEF files for Windows builds. This is just a suggestion. For the content model example all one would need, however, is a FreeContentModel API. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 10:23 Message: Logged In: YES user_id=290026 Fred: I know that, but I just pointed out an example where it would make sense. I have another reason too that has to do with writing wrappers/bindings for Expat, but I will mention it in a reply to your upcoming message on expat-discuss. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-11 09:38 Message: Logged In: YES user_id=3066 Karl: Artyom didn't say he was setting a handler on an XML_Parser object someone else passed him, nor did he say he wasn't. The only specific I see here is that he wants to use the same resource handlers as the parser; it's not clear that this is a real requirement. I'll follow up with a discussion on expat-discuss. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 08:59 Message: Logged In: YES user_id=290026 Once you set an element declaration handler you need to free the content model passed to the handler, so you will need to know the memory handler in use. It is just a rare case that the code that sets the handlers has no control over the code that creates the parser. But it is not too far fetched, so IMO that feature request makes some sense, unless I am overlooking the obvious. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-11 07:40 Message: Logged In: YES user_id=3066 Can you explain why you need the memory handler they've asked Expat to use? The requirements aren't clear, so more explanation of the use case should help. Thanks. ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-12-11 06:32 Message: Logged In: YES user_id=657326 Of course, I know about this. But in my case, I use XML_Parser passed by user (and it is created by him), and I don't know how it was created, either by XML_ParserCreate_MM or not. That is why I requested this function. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-10 21:24 Message: Logged In: YES user_id=290026 Are you creating the parser using XML_ParserCreate? In that case - without supplying an external memory handler, Expat just uses the standard C runtime functions malloc, realloc and free. If you use XML_ParserCreate_MM however, then *you* are supplying the memory handler yourself. In both cases you don't need the requested function. Is your situation different from what I described? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 From noreply at sourceforge.net Wed Dec 11 12:14:45 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Wed Dec 11 15:14:59 2002 Subject: [Expat-bugs] [ expat-Bugs-651754 ] Function to get XML_Memory_Handling_Suite Message-ID: Bugs item #651754, was opened at 2002-12-11 04:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: Function to get XML_Memory_Handling_Suite Initial Comment: It is not a bug report, it is a feature request. What do you think of adding the function, that returns the pointer to XML_Memory_Handling_Suite for passed XML_Parser? It is necessary for me, I am developing an extension for Expat and I would like to use the same allocation/reallocation/free function as the current XML_Parser uses. Since XML_Parser struct defined inside .C-file, I can't get an access to XML_Memory_Handling_Suite struct for the parser. Please add this function, since it will be very simple. Sincerely, Artyom Bolgar. ---------------------------------------------------------------------- >Comment By: Artyom Bolgar (artyom17) Date: 2002-12-11 23:14 Message: Logged In: YES user_id=657326 I am developing an extension to Expat API that provides ability of parsing from any source, from file, network, etc. Of course, I have to make some memory allocations. For example, the function name EXML_CreateFileInputSource (XML_Parser, const char* filename). I don't know how XML_Parser was created, with mem suite or without. But I need to use the same memory functions as parser uses, because user might overload them. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 22:40 Message: Logged In: YES user_id=290026 Attached is a potential patch MemSuite.diff. Includes changes to expat.h, xmlparse.c and the DEF files for Windows builds. This is just a suggestion. For the content model example all one would need, however, is a FreeContentModel API. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 18:23 Message: Logged In: YES user_id=290026 Fred: I know that, but I just pointed out an example where it would make sense. I have another reason too that has to do with writing wrappers/bindings for Expat, but I will mention it in a reply to your upcoming message on expat-discuss. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-11 17:38 Message: Logged In: YES user_id=3066 Karl: Artyom didn't say he was setting a handler on an XML_Parser object someone else passed him, nor did he say he wasn't. The only specific I see here is that he wants to use the same resource handlers as the parser; it's not clear that this is a real requirement. I'll follow up with a discussion on expat-discuss. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 16:59 Message: Logged In: YES user_id=290026 Once you set an element declaration handler you need to free the content model passed to the handler, so you will need to know the memory handler in use. It is just a rare case that the code that sets the handlers has no control over the code that creates the parser. But it is not too far fetched, so IMO that feature request makes some sense, unless I am overlooking the obvious. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-11 15:40 Message: Logged In: YES user_id=3066 Can you explain why you need the memory handler they've asked Expat to use? The requirements aren't clear, so more explanation of the use case should help. Thanks. ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-12-11 14:32 Message: Logged In: YES user_id=657326 Of course, I know about this. But in my case, I use XML_Parser passed by user (and it is created by him), and I don't know how it was created, either by XML_ParserCreate_MM or not. That is why I requested this function. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 05:24 Message: Logged In: YES user_id=290026 Are you creating the parser using XML_ParserCreate? In that case - without supplying an external memory handler, Expat just uses the standard C runtime functions malloc, realloc and free. If you use XML_ParserCreate_MM however, then *you* are supplying the memory handler yourself. In both cases you don't need the requested function. Is your situation different from what I described? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 From noreply at sourceforge.net Wed Dec 11 12:18:35 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Wed Dec 11 15:18:41 2002 Subject: [Expat-bugs] [ expat-Bugs-651754 ] Function to get XML_Memory_Handling_Suite Message-ID: Bugs item #651754, was opened at 2002-12-10 20:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: Function to get XML_Memory_Handling_Suite Initial Comment: It is not a bug report, it is a feature request. What do you think of adding the function, that returns the pointer to XML_Memory_Handling_Suite for passed XML_Parser? It is necessary for me, I am developing an extension for Expat and I would like to use the same allocation/reallocation/free function as the current XML_Parser uses. Since XML_Parser struct defined inside .C-file, I can't get an access to XML_Memory_Handling_Suite struct for the parser. Please add this function, since it will be very simple. Sincerely, Artyom Bolgar. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 15:18 Message: Logged In: YES user_id=290026 Artyom: I am still not clear what you mean with overloading. I don't think you need the same memory handler functions as Expat as long as you don't have to free memory that Expat allocates. ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-12-11 15:14 Message: Logged In: YES user_id=657326 I am developing an extension to Expat API that provides ability of parsing from any source, from file, network, etc. Of course, I have to make some memory allocations. For example, the function name EXML_CreateFileInputSource (XML_Parser, const char* filename). I don't know how XML_Parser was created, with mem suite or without. But I need to use the same memory functions as parser uses, because user might overload them. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 14:40 Message: Logged In: YES user_id=290026 Attached is a potential patch MemSuite.diff. Includes changes to expat.h, xmlparse.c and the DEF files for Windows builds. This is just a suggestion. For the content model example all one would need, however, is a FreeContentModel API. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 10:23 Message: Logged In: YES user_id=290026 Fred: I know that, but I just pointed out an example where it would make sense. I have another reason too that has to do with writing wrappers/bindings for Expat, but I will mention it in a reply to your upcoming message on expat-discuss. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-11 09:38 Message: Logged In: YES user_id=3066 Karl: Artyom didn't say he was setting a handler on an XML_Parser object someone else passed him, nor did he say he wasn't. The only specific I see here is that he wants to use the same resource handlers as the parser; it's not clear that this is a real requirement. I'll follow up with a discussion on expat-discuss. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 08:59 Message: Logged In: YES user_id=290026 Once you set an element declaration handler you need to free the content model passed to the handler, so you will need to know the memory handler in use. It is just a rare case that the code that sets the handlers has no control over the code that creates the parser. But it is not too far fetched, so IMO that feature request makes some sense, unless I am overlooking the obvious. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-11 07:40 Message: Logged In: YES user_id=3066 Can you explain why you need the memory handler they've asked Expat to use? The requirements aren't clear, so more explanation of the use case should help. Thanks. ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-12-11 06:32 Message: Logged In: YES user_id=657326 Of course, I know about this. But in my case, I use XML_Parser passed by user (and it is created by him), and I don't know how it was created, either by XML_ParserCreate_MM or not. That is why I requested this function. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-10 21:24 Message: Logged In: YES user_id=290026 Are you creating the parser using XML_ParserCreate? In that case - without supplying an external memory handler, Expat just uses the standard C runtime functions malloc, realloc and free. If you use XML_ParserCreate_MM however, then *you* are supplying the memory handler yourself. In both cases you don't need the requested function. Is your situation different from what I described? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 From noreply at sourceforge.net Wed Dec 11 13:22:04 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Wed Dec 11 16:22:12 2002 Subject: [Expat-bugs] [ expat-Bugs-651754 ] Function to get XML_Memory_Handling_Suite Message-ID: Bugs item #651754, was opened at 2002-12-11 04:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: Function to get XML_Memory_Handling_Suite Initial Comment: It is not a bug report, it is a feature request. What do you think of adding the function, that returns the pointer to XML_Memory_Handling_Suite for passed XML_Parser? It is necessary for me, I am developing an extension for Expat and I would like to use the same allocation/reallocation/free function as the current XML_Parser uses. Since XML_Parser struct defined inside .C-file, I can't get an access to XML_Memory_Handling_Suite struct for the parser. Please add this function, since it will be very simple. Sincerely, Artyom Bolgar. ---------------------------------------------------------------------- >Comment By: Artyom Bolgar (artyom17) Date: 2002-12-12 00:22 Message: Logged In: YES user_id=657326 Karl, Why user overloads memory allocation functions? Because he don't want to use malloc/realloc/free for some reasons, for example performance or compatibility (some embedded platforms do not support malloc/realloc/free functions). As far as I develops the extension of Expat and it will be linked together with Expat library I want to use the same memory functions as are used by parser. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 23:18 Message: Logged In: YES user_id=290026 Artyom: I am still not clear what you mean with overloading. I don't think you need the same memory handler functions as Expat as long as you don't have to free memory that Expat allocates. ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-12-11 23:14 Message: Logged In: YES user_id=657326 I am developing an extension to Expat API that provides ability of parsing from any source, from file, network, etc. Of course, I have to make some memory allocations. For example, the function name EXML_CreateFileInputSource (XML_Parser, const char* filename). I don't know how XML_Parser was created, with mem suite or without. But I need to use the same memory functions as parser uses, because user might overload them. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 22:40 Message: Logged In: YES user_id=290026 Attached is a potential patch MemSuite.diff. Includes changes to expat.h, xmlparse.c and the DEF files for Windows builds. This is just a suggestion. For the content model example all one would need, however, is a FreeContentModel API. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 18:23 Message: Logged In: YES user_id=290026 Fred: I know that, but I just pointed out an example where it would make sense. I have another reason too that has to do with writing wrappers/bindings for Expat, but I will mention it in a reply to your upcoming message on expat-discuss. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-11 17:38 Message: Logged In: YES user_id=3066 Karl: Artyom didn't say he was setting a handler on an XML_Parser object someone else passed him, nor did he say he wasn't. The only specific I see here is that he wants to use the same resource handlers as the parser; it's not clear that this is a real requirement. I'll follow up with a discussion on expat-discuss. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 16:59 Message: Logged In: YES user_id=290026 Once you set an element declaration handler you need to free the content model passed to the handler, so you will need to know the memory handler in use. It is just a rare case that the code that sets the handlers has no control over the code that creates the parser. But it is not too far fetched, so IMO that feature request makes some sense, unless I am overlooking the obvious. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-11 15:40 Message: Logged In: YES user_id=3066 Can you explain why you need the memory handler they've asked Expat to use? The requirements aren't clear, so more explanation of the use case should help. Thanks. ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-12-11 14:32 Message: Logged In: YES user_id=657326 Of course, I know about this. But in my case, I use XML_Parser passed by user (and it is created by him), and I don't know how it was created, either by XML_ParserCreate_MM or not. That is why I requested this function. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 05:24 Message: Logged In: YES user_id=290026 Are you creating the parser using XML_ParserCreate? In that case - without supplying an external memory handler, Expat just uses the standard C runtime functions malloc, realloc and free. If you use XML_ParserCreate_MM however, then *you* are supplying the memory handler yourself. In both cases you don't need the requested function. Is your situation different from what I described? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 From noreply at sourceforge.net Wed Dec 11 13:38:42 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Wed Dec 11 16:38:53 2002 Subject: [Expat-bugs] [ expat-Bugs-651754 ] Function to get XML_Memory_Handling_Suite Message-ID: Bugs item #651754, was opened at 2002-12-10 20:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: Function to get XML_Memory_Handling_Suite Initial Comment: It is not a bug report, it is a feature request. What do you think of adding the function, that returns the pointer to XML_Memory_Handling_Suite for passed XML_Parser? It is necessary for me, I am developing an extension for Expat and I would like to use the same allocation/reallocation/free function as the current XML_Parser uses. Since XML_Parser struct defined inside .C-file, I can't get an access to XML_Memory_Handling_Suite struct for the parser. Please add this function, since it will be very simple. Sincerely, Artyom Bolgar. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 16:38 Message: Logged In: YES user_id=290026 Artyom, I think I understand now. >From a proper design perspective your use case should not involve Expat. This is a matter between your code and the user's application. It should provide you with the necessary information to use it properly. However, I still think that there is a reason for having an API like the one you suggested: There is one use case where the application has to free memory allocated by the parser (in the element declaration handler). If Expat is not accessed from C/C++, then there may not be a way to do so from languages that can access Dlls, but have different memory allocation implementations. In my case, I am lucky that Delphi's memory manager is basically identical to C/C++, so I can create the parser with the Delphi memory management functions. However, I would have preferred if there was an API like you suggested, or at least a function to free the content model passed to the element declaration handler. ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-12-11 16:22 Message: Logged In: YES user_id=657326 Karl, Why user overloads memory allocation functions? Because he don't want to use malloc/realloc/free for some reasons, for example performance or compatibility (some embedded platforms do not support malloc/realloc/free functions). As far as I develops the extension of Expat and it will be linked together with Expat library I want to use the same memory functions as are used by parser. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 15:18 Message: Logged In: YES user_id=290026 Artyom: I am still not clear what you mean with overloading. I don't think you need the same memory handler functions as Expat as long as you don't have to free memory that Expat allocates. ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-12-11 15:14 Message: Logged In: YES user_id=657326 I am developing an extension to Expat API that provides ability of parsing from any source, from file, network, etc. Of course, I have to make some memory allocations. For example, the function name EXML_CreateFileInputSource (XML_Parser, const char* filename). I don't know how XML_Parser was created, with mem suite or without. But I need to use the same memory functions as parser uses, because user might overload them. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 14:40 Message: Logged In: YES user_id=290026 Attached is a potential patch MemSuite.diff. Includes changes to expat.h, xmlparse.c and the DEF files for Windows builds. This is just a suggestion. For the content model example all one would need, however, is a FreeContentModel API. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 10:23 Message: Logged In: YES user_id=290026 Fred: I know that, but I just pointed out an example where it would make sense. I have another reason too that has to do with writing wrappers/bindings for Expat, but I will mention it in a reply to your upcoming message on expat-discuss. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-11 09:38 Message: Logged In: YES user_id=3066 Karl: Artyom didn't say he was setting a handler on an XML_Parser object someone else passed him, nor did he say he wasn't. The only specific I see here is that he wants to use the same resource handlers as the parser; it's not clear that this is a real requirement. I'll follow up with a discussion on expat-discuss. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-11 08:59 Message: Logged In: YES user_id=290026 Once you set an element declaration handler you need to free the content model passed to the handler, so you will need to know the memory handler in use. It is just a rare case that the code that sets the handlers has no control over the code that creates the parser. But it is not too far fetched, so IMO that feature request makes some sense, unless I am overlooking the obvious. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-11 07:40 Message: Logged In: YES user_id=3066 Can you explain why you need the memory handler they've asked Expat to use? The requirements aren't clear, so more explanation of the use case should help. Thanks. ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-12-11 06:32 Message: Logged In: YES user_id=657326 Of course, I know about this. But in my case, I use XML_Parser passed by user (and it is created by him), and I don't know how it was created, either by XML_ParserCreate_MM or not. That is why I requested this function. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-10 21:24 Message: Logged In: YES user_id=290026 Are you creating the parser using XML_ParserCreate? In that case - without supplying an external memory handler, Expat just uses the standard C runtime functions malloc, realloc and free. If you use XML_ParserCreate_MM however, then *you* are supplying the memory handler yourself. In both cases you don't need the requested function. Is your situation different from what I described? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=651754&group_id=10127 From noreply at sourceforge.net Fri Dec 13 02:01:51 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 13 05:01:55 2002 Subject: [Expat-bugs] [ expat-Bugs-653180 ] problem with column and line numbers Message-ID: Bugs item #653180, was opened at 2002-12-13 11:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: MM Zeeman (mmzeeman) Assigned to: Nobody/Anonymous (nobody) Summary: problem with column and line numbers Initial Comment: XML_GetCurrentColumnNumber returns 2 times the actual column number. The same holds for XML_GetCurrentLineNumber. The XML_GetCurrentByteIndex function returns the correct value. The expat version i'm using is: expat_1.95.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 From noreply at sourceforge.net Fri Dec 13 03:01:16 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 13 06:01:23 2002 Subject: [Expat-bugs] [ expat-Bugs-653180 ] problem with column and line numbers Message-ID: Bugs item #653180, was opened at 2002-12-13 11:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: MM Zeeman (mmzeeman) Assigned to: Nobody/Anonymous (nobody) Summary: problem with column and line numbers Initial Comment: XML_GetCurrentColumnNumber returns 2 times the actual column number. The same holds for XML_GetCurrentLineNumber. The XML_GetCurrentByteIndex function returns the correct value. The expat version i'm using is: expat_1.95.5 ---------------------------------------------------------------------- >Comment By: MM Zeeman (mmzeeman) Date: 2002-12-13 12:01 Message: Logged In: YES user_id=350634 I forgot to add the tests: START_TEST(test_line_number_maas) { char *text = "\n" "\n" "\n"; int lineno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); lineno = XML_GetCurrentLineNumber(parser); if (lineno != 4) { char buffer[100]; sprintf(buffer, "expected 4 lines, saw %d", lineno); fail(buffer); } } END_TEST START_TEST(test_column_number_maas) { char *text = ""; int colno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); colno = XML_GetCurrentColumnNumber(parser); if (colno != 11) { char buffer[100]; sprintf(buffer, "expected 11 columns, saw %d", colno); fail(buffer); } } END_TEST Added to the test suite this resulted in: Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 From noreply at sourceforge.net Fri Dec 13 12:30:28 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 13 15:30:32 2002 Subject: [Expat-bugs] [ expat-Bugs-653449 ] conflicting linkage XmlInitUnknownEncodi Message-ID: Bugs item #653449, was opened at 2002-12-13 23:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653449&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: conflicting linkage XmlInitUnknownEncodi Initial Comment: Expat 1.95.5. When compiling xmltok.c with Sun CC, I was getting a conflicting linkage warning on XmlInitUnknownEncoding. The reason was because the callback function type in the argument list was declared inline. This caused it to be generated with C linkage in the prototype (as declared inside the xmltok.h file inside the 'extern "C"' block) and with C++ linkage in the .c file (because this was not in a C block). Note, Sun CC compiles C-files as C++ ones. The fix was to add the type "CONVERTER" to the xmltok.h file for the callback prototype. This type was then used in the argument list. I attached the diff files for XMLTOK.H and XMLTOK.C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653449&group_id=10127 From noreply at sourceforge.net Fri Dec 13 12:33:31 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 13 15:33:37 2002 Subject: [Expat-bugs] [ expat-Bugs-653449 ] conflicting linkage on XmlInitUnknownEncoding Message-ID: Bugs item #653449, was opened at 2002-12-13 23:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653449&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) >Summary: conflicting linkage on XmlInitUnknownEncoding Initial Comment: Expat 1.95.5. When compiling xmltok.c with Sun CC, I was getting a conflicting linkage warning on XmlInitUnknownEncoding. The reason was because the callback function type in the argument list was declared inline. This caused it to be generated with C linkage in the prototype (as declared inside the xmltok.h file inside the 'extern "C"' block) and with C++ linkage in the .c file (because this was not in a C block). Note, Sun CC compiles C-files as C++ ones. The fix was to add the type "CONVERTER" to the xmltok.h file for the callback prototype. This type was then used in the argument list. I attached the diff files for XMLTOK.H and XMLTOK.C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653449&group_id=10127 From noreply at sourceforge.net Fri Dec 13 18:18:50 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 13 21:18:56 2002 Subject: [Expat-bugs] [ expat-Bugs-653180 ] problem with column and line numbers Message-ID: Bugs item #653180, was opened at 2002-12-13 05:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: MM Zeeman (mmzeeman) >Assigned to: Karl Waclawek (kwaclaw) Summary: problem with column and line numbers Initial Comment: XML_GetCurrentColumnNumber returns 2 times the actual column number. The same holds for XML_GetCurrentLineNumber. The XML_GetCurrentByteIndex function returns the correct value. The expat version i'm using is: expat_1.95.5 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-13 21:18 Message: Logged In: YES user_id=290026 Does this also happen in other situations? For instance: - inside a handler - when XML_Parse returns with an error? ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-13 06:01 Message: Logged In: YES user_id=350634 I forgot to add the tests: START_TEST(test_line_number_maas) { char *text = "\n" "\n" "\n"; int lineno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); lineno = XML_GetCurrentLineNumber(parser); if (lineno != 4) { char buffer[100]; sprintf(buffer, "expected 4 lines, saw %d", lineno); fail(buffer); } } END_TEST START_TEST(test_column_number_maas) { char *text = ""; int colno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); colno = XML_GetCurrentColumnNumber(parser); if (colno != 11) { char buffer[100]; sprintf(buffer, "expected 11 columns, saw %d", colno); fail(buffer); } } END_TEST Added to the test suite this resulted in: Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 From noreply at sourceforge.net Fri Dec 13 19:13:41 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 13 22:13:48 2002 Subject: [Expat-bugs] [ expat-Bugs-653449 ] conflicting linkage on XmlInitUnknownEncoding Message-ID: Bugs item #653449, was opened at 2002-12-13 15:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653449&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Artyom Bolgar (artyom17) >Assigned to: Karl Waclawek (kwaclaw) Summary: conflicting linkage on XmlInitUnknownEncoding Initial Comment: Expat 1.95.5. When compiling xmltok.c with Sun CC, I was getting a conflicting linkage warning on XmlInitUnknownEncoding. The reason was because the callback function type in the argument list was declared inline. This caused it to be generated with C linkage in the prototype (as declared inside the xmltok.h file inside the 'extern "C"' block) and with C++ linkage in the .c file (because this was not in a C block). Note, Sun CC compiles C-files as C++ ones. The fix was to add the type "CONVERTER" to the xmltok.h file for the callback prototype. This type was then used in the argument list. I attached the diff files for XMLTOK.H and XMLTOK.C. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-13 22:13 Message: Logged In: YES user_id=290026 Patch applied in xmltok.h rev. 1.9 and xmltok.c rev. 1.28. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653449&group_id=10127 From noreply at sourceforge.net Sat Dec 14 08:22:49 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Sat Dec 14 11:22:57 2002 Subject: [Expat-bugs] [ expat-Bugs-653180 ] problem with column and line numbers Message-ID: Bugs item #653180, was opened at 2002-12-13 11:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: MM Zeeman (mmzeeman) Assigned to: Karl Waclawek (kwaclaw) Summary: problem with column and line numbers Initial Comment: XML_GetCurrentColumnNumber returns 2 times the actual column number. The same holds for XML_GetCurrentLineNumber. The XML_GetCurrentByteIndex function returns the correct value. The expat version i'm using is: expat_1.95.5 ---------------------------------------------------------------------- >Comment By: MM Zeeman (mmzeeman) Date: 2002-12-14 17:22 Message: Logged In: YES user_id=350634 When I set a start element handler the line number reporting is fine, as long as no trailing newlines are inserted after the last tag. When instead of a start element handler a end element handler is set the line-number is always wrong. Inside the handlers the line-numbers are always ok. I did not check the behavoir for xml_parse errors, or the column number (yet). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-14 03:18 Message: Logged In: YES user_id=290026 Does this also happen in other situations? For instance: - inside a handler - when XML_Parse returns with an error? ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-13 12:01 Message: Logged In: YES user_id=350634 I forgot to add the tests: START_TEST(test_line_number_maas) { char *text = "\n" "\n" "\n"; int lineno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); lineno = XML_GetCurrentLineNumber(parser); if (lineno != 4) { char buffer[100]; sprintf(buffer, "expected 4 lines, saw %d", lineno); fail(buffer); } } END_TEST START_TEST(test_column_number_maas) { char *text = ""; int colno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); colno = XML_GetCurrentColumnNumber(parser); if (colno != 11) { char buffer[100]; sprintf(buffer, "expected 11 columns, saw %d", colno); fail(buffer); } } END_TEST Added to the test suite this resulted in: Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 From noreply at sourceforge.net Sat Dec 14 08:41:33 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Sat Dec 14 11:41:39 2002 Subject: [Expat-bugs] [ expat-Bugs-653180 ] problem with column and line numbers Message-ID: Bugs item #653180, was opened at 2002-12-13 05:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: MM Zeeman (mmzeeman) Assigned to: Karl Waclawek (kwaclaw) Summary: problem with column and line numbers Initial Comment: XML_GetCurrentColumnNumber returns 2 times the actual column number. The same holds for XML_GetCurrentLineNumber. The XML_GetCurrentByteIndex function returns the correct value. The expat version i'm using is: expat_1.95.5 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-14 11:41 Message: Logged In: YES user_id=290026 I have looked a little closer. It seems the numbers are reported OK only if the parser is at the end or beginning of a token, but not in-between. Btw, the line/column number relates to the start of the token, as far as I can tell from the source. In your example, isFinal = 0, so the parser is in-between tokens and expects at least one more call to XML_Parse. I am not sure it is OK to call the line/column number functions in between calls to XML_Parse, since at this point the parser is in the middle of processing a token, while in the other situations (inside a handler, and when having an error) the parser knows exactly what the current token is or is not. One thing is sure: The documentation is not clear and sufficient. Also, from what I can tell, line numbers are 1-based and column numbers are 0-based. I don't think that is a good idea. It should probably be consistent with SAX, where both numbers are 1-based. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-14 11:22 Message: Logged In: YES user_id=350634 When I set a start element handler the line number reporting is fine, as long as no trailing newlines are inserted after the last tag. When instead of a start element handler a end element handler is set the line-number is always wrong. Inside the handlers the line-numbers are always ok. I did not check the behavoir for xml_parse errors, or the column number (yet). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-13 21:18 Message: Logged In: YES user_id=290026 Does this also happen in other situations? For instance: - inside a handler - when XML_Parse returns with an error? ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-13 06:01 Message: Logged In: YES user_id=350634 I forgot to add the tests: START_TEST(test_line_number_maas) { char *text = "\n" "\n" "\n"; int lineno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); lineno = XML_GetCurrentLineNumber(parser); if (lineno != 4) { char buffer[100]; sprintf(buffer, "expected 4 lines, saw %d", lineno); fail(buffer); } } END_TEST START_TEST(test_column_number_maas) { char *text = ""; int colno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); colno = XML_GetCurrentColumnNumber(parser); if (colno != 11) { char buffer[100]; sprintf(buffer, "expected 11 columns, saw %d", colno); fail(buffer); } } END_TEST Added to the test suite this resulted in: Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 From noreply at sourceforge.net Sat Dec 14 21:48:29 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Sun Dec 15 00:48:36 2002 Subject: [Expat-bugs] [ expat-Bugs-653180 ] problem with column and line numbers Message-ID: Bugs item #653180, was opened at 2002-12-13 11:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: MM Zeeman (mmzeeman) Assigned to: Karl Waclawek (kwaclaw) Summary: problem with column and line numbers Initial Comment: XML_GetCurrentColumnNumber returns 2 times the actual column number. The same holds for XML_GetCurrentLineNumber. The XML_GetCurrentByteIndex function returns the correct value. The expat version i'm using is: expat_1.95.5 ---------------------------------------------------------------------- >Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 06:48 Message: Logged In: YES user_id=350634 Hmm, It looks more like the line and column numbers are counted double outside the handlers. When I added this piece of code in front of the update routine the counting was correct. Looking at the source if found that outside the handers the update is called twice. It is first called in parse, and later when you call either XML_GetCurrentLineNumber, or XML_GetCurrentColumnNumber, because for some reason the eventPtr is set. (Which to me seems like this should only be the case in handlers, but I'm not sure) static void FASTCALL PREFIX(updatePosition)(const ENCODING *enc, const char *ptr, const char *end, POSITION *pos) { /* THIS IS NOT CORRECT * Yes, this is lame, but it helps to indicate a double * counting the newlines and column number problem */ static const char *s_ptr = NULL; static const char *s_end = NULL; if( (s_ptr == ptr) && (s_end == end)) /* we already counted this one */ return; s_ptr = ptr; s_end = end; /* The rest of the function */ ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-14 17:41 Message: Logged In: YES user_id=290026 I have looked a little closer. It seems the numbers are reported OK only if the parser is at the end or beginning of a token, but not in-between. Btw, the line/column number relates to the start of the token, as far as I can tell from the source. In your example, isFinal = 0, so the parser is in-between tokens and expects at least one more call to XML_Parse. I am not sure it is OK to call the line/column number functions in between calls to XML_Parse, since at this point the parser is in the middle of processing a token, while in the other situations (inside a handler, and when having an error) the parser knows exactly what the current token is or is not. One thing is sure: The documentation is not clear and sufficient. Also, from what I can tell, line numbers are 1-based and column numbers are 0-based. I don't think that is a good idea. It should probably be consistent with SAX, where both numbers are 1-based. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-14 17:22 Message: Logged In: YES user_id=350634 When I set a start element handler the line number reporting is fine, as long as no trailing newlines are inserted after the last tag. When instead of a start element handler a end element handler is set the line-number is always wrong. Inside the handlers the line-numbers are always ok. I did not check the behavoir for xml_parse errors, or the column number (yet). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-14 03:18 Message: Logged In: YES user_id=290026 Does this also happen in other situations? For instance: - inside a handler - when XML_Parse returns with an error? ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-13 12:01 Message: Logged In: YES user_id=350634 I forgot to add the tests: START_TEST(test_line_number_maas) { char *text = "\n" "\n" "\n"; int lineno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); lineno = XML_GetCurrentLineNumber(parser); if (lineno != 4) { char buffer[100]; sprintf(buffer, "expected 4 lines, saw %d", lineno); fail(buffer); } } END_TEST START_TEST(test_column_number_maas) { char *text = ""; int colno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); colno = XML_GetCurrentColumnNumber(parser); if (colno != 11) { char buffer[100]; sprintf(buffer, "expected 11 columns, saw %d", colno); fail(buffer); } } END_TEST Added to the test suite this resulted in: Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 From noreply at sourceforge.net Sat Dec 14 22:54:48 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Sun Dec 15 01:54:57 2002 Subject: [Expat-bugs] [ expat-Bugs-653180 ] problem with column and line numbers Message-ID: Bugs item #653180, was opened at 2002-12-13 05:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: MM Zeeman (mmzeeman) Assigned to: Karl Waclawek (kwaclaw) Summary: problem with column and line numbers Initial Comment: XML_GetCurrentColumnNumber returns 2 times the actual column number. The same holds for XML_GetCurrentLineNumber. The XML_GetCurrentByteIndex function returns the correct value. The expat version i'm using is: expat_1.95.5 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 01:54 Message: Logged In: YES user_id=290026 Try this - not tested: in XML_Parse(), right after XMLUpdatePosition, insert this line: eventPtr = eventEndPtr = end; and in XML_ParseBuffer, also right after XMLUpdatePosition, insert (as part of the conditional statement): eventPtr = eventEndPtr = bufferPtr; That should hopefully prevent double counting. Haven't really checked possible side-effects. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 00:48 Message: Logged In: YES user_id=350634 Hmm, It looks more like the line and column numbers are counted double outside the handlers. When I added this piece of code in front of the update routine the counting was correct. Looking at the source if found that outside the handers the update is called twice. It is first called in parse, and later when you call either XML_GetCurrentLineNumber, or XML_GetCurrentColumnNumber, because for some reason the eventPtr is set. (Which to me seems like this should only be the case in handlers, but I'm not sure) static void FASTCALL PREFIX(updatePosition)(const ENCODING *enc, const char *ptr, const char *end, POSITION *pos) { /* THIS IS NOT CORRECT * Yes, this is lame, but it helps to indicate a double * counting the newlines and column number problem */ static const char *s_ptr = NULL; static const char *s_end = NULL; if( (s_ptr == ptr) && (s_end == end)) /* we already counted this one */ return; s_ptr = ptr; s_end = end; /* The rest of the function */ ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-14 11:41 Message: Logged In: YES user_id=290026 I have looked a little closer. It seems the numbers are reported OK only if the parser is at the end or beginning of a token, but not in-between. Btw, the line/column number relates to the start of the token, as far as I can tell from the source. In your example, isFinal = 0, so the parser is in-between tokens and expects at least one more call to XML_Parse. I am not sure it is OK to call the line/column number functions in between calls to XML_Parse, since at this point the parser is in the middle of processing a token, while in the other situations (inside a handler, and when having an error) the parser knows exactly what the current token is or is not. One thing is sure: The documentation is not clear and sufficient. Also, from what I can tell, line numbers are 1-based and column numbers are 0-based. I don't think that is a good idea. It should probably be consistent with SAX, where both numbers are 1-based. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-14 11:22 Message: Logged In: YES user_id=350634 When I set a start element handler the line number reporting is fine, as long as no trailing newlines are inserted after the last tag. When instead of a start element handler a end element handler is set the line-number is always wrong. Inside the handlers the line-numbers are always ok. I did not check the behavoir for xml_parse errors, or the column number (yet). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-13 21:18 Message: Logged In: YES user_id=290026 Does this also happen in other situations? For instance: - inside a handler - when XML_Parse returns with an error? ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-13 06:01 Message: Logged In: YES user_id=350634 I forgot to add the tests: START_TEST(test_line_number_maas) { char *text = "\n" "\n" "\n"; int lineno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); lineno = XML_GetCurrentLineNumber(parser); if (lineno != 4) { char buffer[100]; sprintf(buffer, "expected 4 lines, saw %d", lineno); fail(buffer); } } END_TEST START_TEST(test_column_number_maas) { char *text = ""; int colno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); colno = XML_GetCurrentColumnNumber(parser); if (colno != 11) { char buffer[100]; sprintf(buffer, "expected 11 columns, saw %d", colno); fail(buffer); } } END_TEST Added to the test suite this resulted in: Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 From noreply at sourceforge.net Sun Dec 15 08:20:05 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Sun Dec 15 11:20:13 2002 Subject: [Expat-bugs] [ expat-Bugs-653180 ] problem with column and line numbers Message-ID: Bugs item #653180, was opened at 2002-12-13 11:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: MM Zeeman (mmzeeman) Assigned to: Karl Waclawek (kwaclaw) Summary: problem with column and line numbers Initial Comment: XML_GetCurrentColumnNumber returns 2 times the actual column number. The same holds for XML_GetCurrentLineNumber. The XML_GetCurrentByteIndex function returns the correct value. The expat version i'm using is: expat_1.95.5 ---------------------------------------------------------------------- >Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 17:20 Message: Logged In: YES user_id=350634 No, this does not solve the problem. tests/runtests Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 make: *** [check] Error 1 Btw, this whole line/column counting seems to be one big side-effect ;) Why is it not implemented as part of the normal scanning routines. It seems like the buffer passed to XML_Parse will be checked (again) just to adjust the line and column numbers. During the "normal" scanning phase nothing is done to adjust the line and column numbers. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 07:54 Message: Logged In: YES user_id=290026 Try this - not tested: in XML_Parse(), right after XMLUpdatePosition, insert this line: eventPtr = eventEndPtr = end; and in XML_ParseBuffer, also right after XMLUpdatePosition, insert (as part of the conditional statement): eventPtr = eventEndPtr = bufferPtr; That should hopefully prevent double counting. Haven't really checked possible side-effects. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 06:48 Message: Logged In: YES user_id=350634 Hmm, It looks more like the line and column numbers are counted double outside the handlers. When I added this piece of code in front of the update routine the counting was correct. Looking at the source if found that outside the handers the update is called twice. It is first called in parse, and later when you call either XML_GetCurrentLineNumber, or XML_GetCurrentColumnNumber, because for some reason the eventPtr is set. (Which to me seems like this should only be the case in handlers, but I'm not sure) static void FASTCALL PREFIX(updatePosition)(const ENCODING *enc, const char *ptr, const char *end, POSITION *pos) { /* THIS IS NOT CORRECT * Yes, this is lame, but it helps to indicate a double * counting the newlines and column number problem */ static const char *s_ptr = NULL; static const char *s_end = NULL; if( (s_ptr == ptr) && (s_end == end)) /* we already counted this one */ return; s_ptr = ptr; s_end = end; /* The rest of the function */ ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-14 17:41 Message: Logged In: YES user_id=290026 I have looked a little closer. It seems the numbers are reported OK only if the parser is at the end or beginning of a token, but not in-between. Btw, the line/column number relates to the start of the token, as far as I can tell from the source. In your example, isFinal = 0, so the parser is in-between tokens and expects at least one more call to XML_Parse. I am not sure it is OK to call the line/column number functions in between calls to XML_Parse, since at this point the parser is in the middle of processing a token, while in the other situations (inside a handler, and when having an error) the parser knows exactly what the current token is or is not. One thing is sure: The documentation is not clear and sufficient. Also, from what I can tell, line numbers are 1-based and column numbers are 0-based. I don't think that is a good idea. It should probably be consistent with SAX, where both numbers are 1-based. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-14 17:22 Message: Logged In: YES user_id=350634 When I set a start element handler the line number reporting is fine, as long as no trailing newlines are inserted after the last tag. When instead of a start element handler a end element handler is set the line-number is always wrong. Inside the handlers the line-numbers are always ok. I did not check the behavoir for xml_parse errors, or the column number (yet). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-14 03:18 Message: Logged In: YES user_id=290026 Does this also happen in other situations? For instance: - inside a handler - when XML_Parse returns with an error? ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-13 12:01 Message: Logged In: YES user_id=350634 I forgot to add the tests: START_TEST(test_line_number_maas) { char *text = "\n" "\n" "\n"; int lineno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); lineno = XML_GetCurrentLineNumber(parser); if (lineno != 4) { char buffer[100]; sprintf(buffer, "expected 4 lines, saw %d", lineno); fail(buffer); } } END_TEST START_TEST(test_column_number_maas) { char *text = ""; int colno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); colno = XML_GetCurrentColumnNumber(parser); if (colno != 11) { char buffer[100]; sprintf(buffer, "expected 11 columns, saw %d", colno); fail(buffer); } } END_TEST Added to the test suite this resulted in: Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 From noreply at sourceforge.net Sun Dec 15 08:34:02 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Sun Dec 15 11:34:08 2002 Subject: [Expat-bugs] [ expat-Bugs-653180 ] problem with column and line numbers Message-ID: Bugs item #653180, was opened at 2002-12-13 05:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: MM Zeeman (mmzeeman) Assigned to: Karl Waclawek (kwaclaw) Summary: problem with column and line numbers Initial Comment: XML_GetCurrentColumnNumber returns 2 times the actual column number. The same holds for XML_GetCurrentLineNumber. The XML_GetCurrentByteIndex function returns the correct value. The expat version i'm using is: expat_1.95.5 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 11:34 Message: Logged In: YES user_id=290026 OK, I think this will be better. Same places as before, but instead of the previous statements insert these after XMLUpdatePosition: in XML_Parse(): positionPtr = end; in XML_ParseBuffer(): positionPtr = bufferPtr; Why is it not part of the scanning routines? I can only guess, since I didn't write it. I would say that a) it would make the code even more complicated b) it would likely not be faster ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 11:20 Message: Logged In: YES user_id=350634 No, this does not solve the problem. tests/runtests Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 make: *** [check] Error 1 Btw, this whole line/column counting seems to be one big side-effect ;) Why is it not implemented as part of the normal scanning routines. It seems like the buffer passed to XML_Parse will be checked (again) just to adjust the line and column numbers. During the "normal" scanning phase nothing is done to adjust the line and column numbers. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 01:54 Message: Logged In: YES user_id=290026 Try this - not tested: in XML_Parse(), right after XMLUpdatePosition, insert this line: eventPtr = eventEndPtr = end; and in XML_ParseBuffer, also right after XMLUpdatePosition, insert (as part of the conditional statement): eventPtr = eventEndPtr = bufferPtr; That should hopefully prevent double counting. Haven't really checked possible side-effects. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 00:48 Message: Logged In: YES user_id=350634 Hmm, It looks more like the line and column numbers are counted double outside the handlers. When I added this piece of code in front of the update routine the counting was correct. Looking at the source if found that outside the handers the update is called twice. It is first called in parse, and later when you call either XML_GetCurrentLineNumber, or XML_GetCurrentColumnNumber, because for some reason the eventPtr is set. (Which to me seems like this should only be the case in handlers, but I'm not sure) static void FASTCALL PREFIX(updatePosition)(const ENCODING *enc, const char *ptr, const char *end, POSITION *pos) { /* THIS IS NOT CORRECT * Yes, this is lame, but it helps to indicate a double * counting the newlines and column number problem */ static const char *s_ptr = NULL; static const char *s_end = NULL; if( (s_ptr == ptr) && (s_end == end)) /* we already counted this one */ return; s_ptr = ptr; s_end = end; /* The rest of the function */ ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-14 11:41 Message: Logged In: YES user_id=290026 I have looked a little closer. It seems the numbers are reported OK only if the parser is at the end or beginning of a token, but not in-between. Btw, the line/column number relates to the start of the token, as far as I can tell from the source. In your example, isFinal = 0, so the parser is in-between tokens and expects at least one more call to XML_Parse. I am not sure it is OK to call the line/column number functions in between calls to XML_Parse, since at this point the parser is in the middle of processing a token, while in the other situations (inside a handler, and when having an error) the parser knows exactly what the current token is or is not. One thing is sure: The documentation is not clear and sufficient. Also, from what I can tell, line numbers are 1-based and column numbers are 0-based. I don't think that is a good idea. It should probably be consistent with SAX, where both numbers are 1-based. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-14 11:22 Message: Logged In: YES user_id=350634 When I set a start element handler the line number reporting is fine, as long as no trailing newlines are inserted after the last tag. When instead of a start element handler a end element handler is set the line-number is always wrong. Inside the handlers the line-numbers are always ok. I did not check the behavoir for xml_parse errors, or the column number (yet). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-13 21:18 Message: Logged In: YES user_id=290026 Does this also happen in other situations? For instance: - inside a handler - when XML_Parse returns with an error? ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-13 06:01 Message: Logged In: YES user_id=350634 I forgot to add the tests: START_TEST(test_line_number_maas) { char *text = "\n" "\n" "\n"; int lineno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); lineno = XML_GetCurrentLineNumber(parser); if (lineno != 4) { char buffer[100]; sprintf(buffer, "expected 4 lines, saw %d", lineno); fail(buffer); } } END_TEST START_TEST(test_column_number_maas) { char *text = ""; int colno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); colno = XML_GetCurrentColumnNumber(parser); if (colno != 11) { char buffer[100]; sprintf(buffer, "expected 11 columns, saw %d", colno); fail(buffer); } } END_TEST Added to the test suite this resulted in: Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 From noreply at sourceforge.net Sun Dec 15 11:07:22 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Sun Dec 15 14:07:30 2002 Subject: [Expat-bugs] [ expat-Bugs-653180 ] problem with column and line numbers Message-ID: Bugs item #653180, was opened at 2002-12-13 11:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: MM Zeeman (mmzeeman) Assigned to: Karl Waclawek (kwaclaw) Summary: problem with column and line numbers Initial Comment: XML_GetCurrentColumnNumber returns 2 times the actual column number. The same holds for XML_GetCurrentLineNumber. The XML_GetCurrentByteIndex function returns the correct value. The expat version i'm using is: expat_1.95.5 ---------------------------------------------------------------------- >Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 20:07 Message: Logged In: YES user_id=350634 Thanks, this solved the problem. This was the first time I looked at the expat code, so I was a bit surprised to see that XML parsing is not as simple as I thought it would be. On the other hand, maybe the code needs to be refactored here and there too. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 17:34 Message: Logged In: YES user_id=290026 OK, I think this will be better. Same places as before, but instead of the previous statements insert these after XMLUpdatePosition: in XML_Parse(): positionPtr = end; in XML_ParseBuffer(): positionPtr = bufferPtr; Why is it not part of the scanning routines? I can only guess, since I didn't write it. I would say that a) it would make the code even more complicated b) it would likely not be faster ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 17:20 Message: Logged In: YES user_id=350634 No, this does not solve the problem. tests/runtests Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 make: *** [check] Error 1 Btw, this whole line/column counting seems to be one big side-effect ;) Why is it not implemented as part of the normal scanning routines. It seems like the buffer passed to XML_Parse will be checked (again) just to adjust the line and column numbers. During the "normal" scanning phase nothing is done to adjust the line and column numbers. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 07:54 Message: Logged In: YES user_id=290026 Try this - not tested: in XML_Parse(), right after XMLUpdatePosition, insert this line: eventPtr = eventEndPtr = end; and in XML_ParseBuffer, also right after XMLUpdatePosition, insert (as part of the conditional statement): eventPtr = eventEndPtr = bufferPtr; That should hopefully prevent double counting. Haven't really checked possible side-effects. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 06:48 Message: Logged In: YES user_id=350634 Hmm, It looks more like the line and column numbers are counted double outside the handlers. When I added this piece of code in front of the update routine the counting was correct. Looking at the source if found that outside the handers the update is called twice. It is first called in parse, and later when you call either XML_GetCurrentLineNumber, or XML_GetCurrentColumnNumber, because for some reason the eventPtr is set. (Which to me seems like this should only be the case in handlers, but I'm not sure) static void FASTCALL PREFIX(updatePosition)(const ENCODING *enc, const char *ptr, const char *end, POSITION *pos) { /* THIS IS NOT CORRECT * Yes, this is lame, but it helps to indicate a double * counting the newlines and column number problem */ static const char *s_ptr = NULL; static const char *s_end = NULL; if( (s_ptr == ptr) && (s_end == end)) /* we already counted this one */ return; s_ptr = ptr; s_end = end; /* The rest of the function */ ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-14 17:41 Message: Logged In: YES user_id=290026 I have looked a little closer. It seems the numbers are reported OK only if the parser is at the end or beginning of a token, but not in-between. Btw, the line/column number relates to the start of the token, as far as I can tell from the source. In your example, isFinal = 0, so the parser is in-between tokens and expects at least one more call to XML_Parse. I am not sure it is OK to call the line/column number functions in between calls to XML_Parse, since at this point the parser is in the middle of processing a token, while in the other situations (inside a handler, and when having an error) the parser knows exactly what the current token is or is not. One thing is sure: The documentation is not clear and sufficient. Also, from what I can tell, line numbers are 1-based and column numbers are 0-based. I don't think that is a good idea. It should probably be consistent with SAX, where both numbers are 1-based. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-14 17:22 Message: Logged In: YES user_id=350634 When I set a start element handler the line number reporting is fine, as long as no trailing newlines are inserted after the last tag. When instead of a start element handler a end element handler is set the line-number is always wrong. Inside the handlers the line-numbers are always ok. I did not check the behavoir for xml_parse errors, or the column number (yet). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-14 03:18 Message: Logged In: YES user_id=290026 Does this also happen in other situations? For instance: - inside a handler - when XML_Parse returns with an error? ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-13 12:01 Message: Logged In: YES user_id=350634 I forgot to add the tests: START_TEST(test_line_number_maas) { char *text = "\n" "\n" "\n"; int lineno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); lineno = XML_GetCurrentLineNumber(parser); if (lineno != 4) { char buffer[100]; sprintf(buffer, "expected 4 lines, saw %d", lineno); fail(buffer); } } END_TEST START_TEST(test_column_number_maas) { char *text = ""; int colno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); colno = XML_GetCurrentColumnNumber(parser); if (colno != 11) { char buffer[100]; sprintf(buffer, "expected 11 columns, saw %d", colno); fail(buffer); } } END_TEST Added to the test suite this resulted in: Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 From noreply at sourceforge.net Sun Dec 15 12:05:47 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Sun Dec 15 15:06:01 2002 Subject: [Expat-bugs] [ expat-Bugs-653180 ] problem with column and line numbers Message-ID: Bugs item #653180, was opened at 2002-12-13 05:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 Category: None >Group: Test Required Status: Open >Resolution: Fixed Priority: 5 Submitted By: MM Zeeman (mmzeeman) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: problem with column and line numbers Initial Comment: XML_GetCurrentColumnNumber returns 2 times the actual column number. The same holds for XML_GetCurrentLineNumber. The XML_GetCurrentByteIndex function returns the correct value. The expat version i'm using is: expat_1.95.5 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 15:05 Message: Logged In: YES user_id=290026 Great - I will apply a patch to CVS. Could you please subject it to a few tests for other situations, like: - calling the line/column functions after an error - calling them in a handler And report back here. If OK, this patch will go into the next release, which is coming soon. To Fred Drake: Fred, seems there is already a regression test case in the posts below. Would you please add it. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 14:07 Message: Logged In: YES user_id=350634 Thanks, this solved the problem. This was the first time I looked at the expat code, so I was a bit surprised to see that XML parsing is not as simple as I thought it would be. On the other hand, maybe the code needs to be refactored here and there too. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 11:34 Message: Logged In: YES user_id=290026 OK, I think this will be better. Same places as before, but instead of the previous statements insert these after XMLUpdatePosition: in XML_Parse(): positionPtr = end; in XML_ParseBuffer(): positionPtr = bufferPtr; Why is it not part of the scanning routines? I can only guess, since I didn't write it. I would say that a) it would make the code even more complicated b) it would likely not be faster ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 11:20 Message: Logged In: YES user_id=350634 No, this does not solve the problem. tests/runtests Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 make: *** [check] Error 1 Btw, this whole line/column counting seems to be one big side-effect ;) Why is it not implemented as part of the normal scanning routines. It seems like the buffer passed to XML_Parse will be checked (again) just to adjust the line and column numbers. During the "normal" scanning phase nothing is done to adjust the line and column numbers. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 01:54 Message: Logged In: YES user_id=290026 Try this - not tested: in XML_Parse(), right after XMLUpdatePosition, insert this line: eventPtr = eventEndPtr = end; and in XML_ParseBuffer, also right after XMLUpdatePosition, insert (as part of the conditional statement): eventPtr = eventEndPtr = bufferPtr; That should hopefully prevent double counting. Haven't really checked possible side-effects. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 00:48 Message: Logged In: YES user_id=350634 Hmm, It looks more like the line and column numbers are counted double outside the handlers. When I added this piece of code in front of the update routine the counting was correct. Looking at the source if found that outside the handers the update is called twice. It is first called in parse, and later when you call either XML_GetCurrentLineNumber, or XML_GetCurrentColumnNumber, because for some reason the eventPtr is set. (Which to me seems like this should only be the case in handlers, but I'm not sure) static void FASTCALL PREFIX(updatePosition)(const ENCODING *enc, const char *ptr, const char *end, POSITION *pos) { /* THIS IS NOT CORRECT * Yes, this is lame, but it helps to indicate a double * counting the newlines and column number problem */ static const char *s_ptr = NULL; static const char *s_end = NULL; if( (s_ptr == ptr) && (s_end == end)) /* we already counted this one */ return; s_ptr = ptr; s_end = end; /* The rest of the function */ ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-14 11:41 Message: Logged In: YES user_id=290026 I have looked a little closer. It seems the numbers are reported OK only if the parser is at the end or beginning of a token, but not in-between. Btw, the line/column number relates to the start of the token, as far as I can tell from the source. In your example, isFinal = 0, so the parser is in-between tokens and expects at least one more call to XML_Parse. I am not sure it is OK to call the line/column number functions in between calls to XML_Parse, since at this point the parser is in the middle of processing a token, while in the other situations (inside a handler, and when having an error) the parser knows exactly what the current token is or is not. One thing is sure: The documentation is not clear and sufficient. Also, from what I can tell, line numbers are 1-based and column numbers are 0-based. I don't think that is a good idea. It should probably be consistent with SAX, where both numbers are 1-based. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-14 11:22 Message: Logged In: YES user_id=350634 When I set a start element handler the line number reporting is fine, as long as no trailing newlines are inserted after the last tag. When instead of a start element handler a end element handler is set the line-number is always wrong. Inside the handlers the line-numbers are always ok. I did not check the behavoir for xml_parse errors, or the column number (yet). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-13 21:18 Message: Logged In: YES user_id=290026 Does this also happen in other situations? For instance: - inside a handler - when XML_Parse returns with an error? ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-13 06:01 Message: Logged In: YES user_id=350634 I forgot to add the tests: START_TEST(test_line_number_maas) { char *text = "\n" "\n" "\n"; int lineno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); lineno = XML_GetCurrentLineNumber(parser); if (lineno != 4) { char buffer[100]; sprintf(buffer, "expected 4 lines, saw %d", lineno); fail(buffer); } } END_TEST START_TEST(test_column_number_maas) { char *text = ""; int colno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); colno = XML_GetCurrentColumnNumber(parser); if (colno != 11) { char buffer[100]; sprintf(buffer, "expected 11 columns, saw %d", colno); fail(buffer); } } END_TEST Added to the test suite this resulted in: Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 From noreply at sourceforge.net Sun Dec 15 19:49:06 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Sun Dec 15 22:52:21 2002 Subject: [Expat-bugs] [ expat-Bugs-653180 ] problem with column and line numbers Message-ID: Bugs item #653180, was opened at 2002-12-13 05:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 Category: None Group: Test Required Status: Open Resolution: Fixed Priority: 5 Submitted By: MM Zeeman (mmzeeman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: problem with column and line numbers Initial Comment: XML_GetCurrentColumnNumber returns 2 times the actual column number. The same holds for XML_GetCurrentLineNumber. The XML_GetCurrentByteIndex function returns the correct value. The expat version i'm using is: expat_1.95.5 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 22:49 Message: Logged In: YES user_id=290026 Just a comment: According to the documentation in expat.h, the line/column number functions should only be called when XML_Parse or XML_ParseBuffer return 0 (error) or from callback handlers. So, strictly speaking, this was not a bug. Another question - mostly for Fred: Why is it that line numbers are 1-based, and column numbers are 0-based? If we keep this behaviour then we should at least document it! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 15:05 Message: Logged In: YES user_id=290026 Great - I will apply a patch to CVS. Could you please subject it to a few tests for other situations, like: - calling the line/column functions after an error - calling them in a handler And report back here. If OK, this patch will go into the next release, which is coming soon. To Fred Drake: Fred, seems there is already a regression test case in the posts below. Would you please add it. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 14:07 Message: Logged In: YES user_id=350634 Thanks, this solved the problem. This was the first time I looked at the expat code, so I was a bit surprised to see that XML parsing is not as simple as I thought it would be. On the other hand, maybe the code needs to be refactored here and there too. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 11:34 Message: Logged In: YES user_id=290026 OK, I think this will be better. Same places as before, but instead of the previous statements insert these after XMLUpdatePosition: in XML_Parse(): positionPtr = end; in XML_ParseBuffer(): positionPtr = bufferPtr; Why is it not part of the scanning routines? I can only guess, since I didn't write it. I would say that a) it would make the code even more complicated b) it would likely not be faster ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 11:20 Message: Logged In: YES user_id=350634 No, this does not solve the problem. tests/runtests Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 make: *** [check] Error 1 Btw, this whole line/column counting seems to be one big side-effect ;) Why is it not implemented as part of the normal scanning routines. It seems like the buffer passed to XML_Parse will be checked (again) just to adjust the line and column numbers. During the "normal" scanning phase nothing is done to adjust the line and column numbers. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 01:54 Message: Logged In: YES user_id=290026 Try this - not tested: in XML_Parse(), right after XMLUpdatePosition, insert this line: eventPtr = eventEndPtr = end; and in XML_ParseBuffer, also right after XMLUpdatePosition, insert (as part of the conditional statement): eventPtr = eventEndPtr = bufferPtr; That should hopefully prevent double counting. Haven't really checked possible side-effects. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 00:48 Message: Logged In: YES user_id=350634 Hmm, It looks more like the line and column numbers are counted double outside the handlers. When I added this piece of code in front of the update routine the counting was correct. Looking at the source if found that outside the handers the update is called twice. It is first called in parse, and later when you call either XML_GetCurrentLineNumber, or XML_GetCurrentColumnNumber, because for some reason the eventPtr is set. (Which to me seems like this should only be the case in handlers, but I'm not sure) static void FASTCALL PREFIX(updatePosition)(const ENCODING *enc, const char *ptr, const char *end, POSITION *pos) { /* THIS IS NOT CORRECT * Yes, this is lame, but it helps to indicate a double * counting the newlines and column number problem */ static const char *s_ptr = NULL; static const char *s_end = NULL; if( (s_ptr == ptr) && (s_end == end)) /* we already counted this one */ return; s_ptr = ptr; s_end = end; /* The rest of the function */ ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-14 11:41 Message: Logged In: YES user_id=290026 I have looked a little closer. It seems the numbers are reported OK only if the parser is at the end or beginning of a token, but not in-between. Btw, the line/column number relates to the start of the token, as far as I can tell from the source. In your example, isFinal = 0, so the parser is in-between tokens and expects at least one more call to XML_Parse. I am not sure it is OK to call the line/column number functions in between calls to XML_Parse, since at this point the parser is in the middle of processing a token, while in the other situations (inside a handler, and when having an error) the parser knows exactly what the current token is or is not. One thing is sure: The documentation is not clear and sufficient. Also, from what I can tell, line numbers are 1-based and column numbers are 0-based. I don't think that is a good idea. It should probably be consistent with SAX, where both numbers are 1-based. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-14 11:22 Message: Logged In: YES user_id=350634 When I set a start element handler the line number reporting is fine, as long as no trailing newlines are inserted after the last tag. When instead of a start element handler a end element handler is set the line-number is always wrong. Inside the handlers the line-numbers are always ok. I did not check the behavoir for xml_parse errors, or the column number (yet). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-13 21:18 Message: Logged In: YES user_id=290026 Does this also happen in other situations? For instance: - inside a handler - when XML_Parse returns with an error? ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-13 06:01 Message: Logged In: YES user_id=350634 I forgot to add the tests: START_TEST(test_line_number_maas) { char *text = "\n" "\n" "\n"; int lineno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); lineno = XML_GetCurrentLineNumber(parser); if (lineno != 4) { char buffer[100]; sprintf(buffer, "expected 4 lines, saw %d", lineno); fail(buffer); } } END_TEST START_TEST(test_column_number_maas) { char *text = ""; int colno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); colno = XML_GetCurrentColumnNumber(parser); if (colno != 11) { char buffer[100]; sprintf(buffer, "expected 11 columns, saw %d", colno); fail(buffer); } } END_TEST Added to the test suite this resulted in: Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 From noreply at sourceforge.net Mon Dec 16 08:18:34 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Mon Dec 16 11:18:43 2002 Subject: [Expat-bugs] [ expat-Bugs-653180 ] problem with column and line numbers Message-ID: Bugs item #653180, was opened at 2002-12-13 02:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 Category: None Group: Test Required Status: Open Resolution: Fixed Priority: 5 Submitted By: MM Zeeman (mmzeeman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: problem with column and line numbers Initial Comment: XML_GetCurrentColumnNumber returns 2 times the actual column number. The same holds for XML_GetCurrentLineNumber. The XML_GetCurrentByteIndex function returns the correct value. The expat version i'm using is: expat_1.95.5 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-12-16 08:18 Message: Logged In: NO The HTML documentation tells me something different. It indeed starts with an indication stating that these functions are useful when XML_Parse returns 0, but also that they are quote "the position reporting functions are useful outside of errors. " It only states that it can not be used inside a DTD. So the situation was not really clear. What was clear is that calling the line or column number function outside an handler before final resulted in a wrong answer, and as a bonus goofes up the further line and column number reports. Btw I still think, Expat is a really good XML library. It has a nice API, which makes it easy to create wrappers (I was working on an expat wrapper for OCaml) Here are the tests you requested: /* * Line and column numbers inside handlers test */ static void start_element_event_handler2(void *userData, const XML_Char *name, const XML_Char **attr) { CharData *storage = (CharData *) userData; char buffer[100]; sprintf(buffer, "<%s> at col:%d line:%d\n", name, XML_GetCurrentColumnNumber(parser), XML_GetCurrentLineNumber(parser)); CharData_AppendString(storage, buffer); } static void end_element_event_handler2(void *userData, const XML_Char *name) { CharData *storage = (CharData *) userData; char buffer[100]; sprintf(buffer, " at col:%d line:%d\n", name, XML_GetCurrentColumnNumber(parser), XML_GetCurrentLineNumber(parser)); CharData_AppendString(storage, buffer); } START_TEST(test_line_and_column_numbers_inside_handlers) { char *text = "\n" /* the unix idea of an end-of-line */ " \r\n" /* the windows of an end-of-line*/ " \r" /* also counts as an end-of-line */ " \n" " \n" " \n" " \n" ""; char *expected = " at col:0 line:1\n" " at col:2 line:2\n" " at col:4 line:3\n" " at col:8 line:3\n" " at col:2 line:4\n" " at col:2 line:5\n" " at col:4 line:6\n" " at col:8 line:6\n" " at col:2 line:7\n" " at col:0 line:8\n"; CharData storage; CharData_Init(&storage); XML_SetUserData(parser, &storage); XML_SetStartElementHandler(parser, start_element_event_handler2); XML_SetEndElementHandler(parser, end_element_event_handler2); if (XML_Parse(parser, text, strlen(text), 1) == XML_STATUS_ERROR) xml_failure(parser); CharData_CheckString(&storage, expected); } END_TEST START_TEST(test_line_number_after_error) { char *text = "\n" " \n" " "; /* missing */ int lineno; if (XML_Parse(parser, text, strlen(text), 0) != XML_STATUS_ERROR) fail("Expected a parse error"); lineno = XML_GetCurrentLineNumber(parser); if (lineno != 3) { char buffer[100]; sprintf(buffer, "expected 3 lines, saw %d", lineno); fail(buffer); } } END_TEST START_TEST(test_column_number_after_error) { char *text = "\n" " \n" " "; /* missing */ int colno; if (XML_Parse(parser, text, strlen(text), 0) != XML_STATUS_ERROR) fail("Expected a parse error"); colno = XML_GetCurrentColumnNumber(parser); if (colno != 4) { char buffer[100]; sprintf(buffer, "expected 4 columns, saw %d", colno); fail(buffer); } } END_TEST ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 19:49 Message: Logged In: YES user_id=290026 Just a comment: According to the documentation in expat.h, the line/column number functions should only be called when XML_Parse or XML_ParseBuffer return 0 (error) or from callback handlers. So, strictly speaking, this was not a bug. Another question - mostly for Fred: Why is it that line numbers are 1-based, and column numbers are 0-based? If we keep this behaviour then we should at least document it! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 12:05 Message: Logged In: YES user_id=290026 Great - I will apply a patch to CVS. Could you please subject it to a few tests for other situations, like: - calling the line/column functions after an error - calling them in a handler And report back here. If OK, this patch will go into the next release, which is coming soon. To Fred Drake: Fred, seems there is already a regression test case in the posts below. Would you please add it. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 11:07 Message: Logged In: YES user_id=350634 Thanks, this solved the problem. This was the first time I looked at the expat code, so I was a bit surprised to see that XML parsing is not as simple as I thought it would be. On the other hand, maybe the code needs to be refactored here and there too. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 08:34 Message: Logged In: YES user_id=290026 OK, I think this will be better. Same places as before, but instead of the previous statements insert these after XMLUpdatePosition: in XML_Parse(): positionPtr = end; in XML_ParseBuffer(): positionPtr = bufferPtr; Why is it not part of the scanning routines? I can only guess, since I didn't write it. I would say that a) it would make the code even more complicated b) it would likely not be faster ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 08:20 Message: Logged In: YES user_id=350634 No, this does not solve the problem. tests/runtests Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 make: *** [check] Error 1 Btw, this whole line/column counting seems to be one big side-effect ;) Why is it not implemented as part of the normal scanning routines. It seems like the buffer passed to XML_Parse will be checked (again) just to adjust the line and column numbers. During the "normal" scanning phase nothing is done to adjust the line and column numbers. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-14 22:54 Message: Logged In: YES user_id=290026 Try this - not tested: in XML_Parse(), right after XMLUpdatePosition, insert this line: eventPtr = eventEndPtr = end; and in XML_ParseBuffer, also right after XMLUpdatePosition, insert (as part of the conditional statement): eventPtr = eventEndPtr = bufferPtr; That should hopefully prevent double counting. Haven't really checked possible side-effects. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-14 21:48 Message: Logged In: YES user_id=350634 Hmm, It looks more like the line and column numbers are counted double outside the handlers. When I added this piece of code in front of the update routine the counting was correct. Looking at the source if found that outside the handers the update is called twice. It is first called in parse, and later when you call either XML_GetCurrentLineNumber, or XML_GetCurrentColumnNumber, because for some reason the eventPtr is set. (Which to me seems like this should only be the case in handlers, but I'm not sure) static void FASTCALL PREFIX(updatePosition)(const ENCODING *enc, const char *ptr, const char *end, POSITION *pos) { /* THIS IS NOT CORRECT * Yes, this is lame, but it helps to indicate a double * counting the newlines and column number problem */ static const char *s_ptr = NULL; static const char *s_end = NULL; if( (s_ptr == ptr) && (s_end == end)) /* we already counted this one */ return; s_ptr = ptr; s_end = end; /* The rest of the function */ ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-14 08:41 Message: Logged In: YES user_id=290026 I have looked a little closer. It seems the numbers are reported OK only if the parser is at the end or beginning of a token, but not in-between. Btw, the line/column number relates to the start of the token, as far as I can tell from the source. In your example, isFinal = 0, so the parser is in-between tokens and expects at least one more call to XML_Parse. I am not sure it is OK to call the line/column number functions in between calls to XML_Parse, since at this point the parser is in the middle of processing a token, while in the other situations (inside a handler, and when having an error) the parser knows exactly what the current token is or is not. One thing is sure: The documentation is not clear and sufficient. Also, from what I can tell, line numbers are 1-based and column numbers are 0-based. I don't think that is a good idea. It should probably be consistent with SAX, where both numbers are 1-based. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-14 08:22 Message: Logged In: YES user_id=350634 When I set a start element handler the line number reporting is fine, as long as no trailing newlines are inserted after the last tag. When instead of a start element handler a end element handler is set the line-number is always wrong. Inside the handlers the line-numbers are always ok. I did not check the behavoir for xml_parse errors, or the column number (yet). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-13 18:18 Message: Logged In: YES user_id=290026 Does this also happen in other situations? For instance: - inside a handler - when XML_Parse returns with an error? ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-13 03:01 Message: Logged In: YES user_id=350634 I forgot to add the tests: START_TEST(test_line_number_maas) { char *text = "\n" "\n" "\n"; int lineno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); lineno = XML_GetCurrentLineNumber(parser); if (lineno != 4) { char buffer[100]; sprintf(buffer, "expected 4 lines, saw %d", lineno); fail(buffer); } } END_TEST START_TEST(test_column_number_maas) { char *text = ""; int colno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); colno = XML_GetCurrentColumnNumber(parser); if (colno != 11) { char buffer[100]; sprintf(buffer, "expected 11 columns, saw %d", colno); fail(buffer); } } END_TEST Added to the test suite this resulted in: Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 From noreply at sourceforge.net Mon Dec 16 09:33:26 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Mon Dec 16 12:33:38 2002 Subject: [Expat-bugs] [ expat-Bugs-653180 ] problem with column and line numbers Message-ID: Bugs item #653180, was opened at 2002-12-13 05:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 Category: None Group: Test Required Status: Open Resolution: Fixed Priority: 5 Submitted By: MM Zeeman (mmzeeman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: problem with column and line numbers Initial Comment: XML_GetCurrentColumnNumber returns 2 times the actual column number. The same holds for XML_GetCurrentLineNumber. The XML_GetCurrentByteIndex function returns the correct value. The expat version i'm using is: expat_1.95.5 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-16 12:33 Message: Logged In: YES user_id=290026 Thanks a lot for the test cases. We are really grateful when somebody helps out! After all, this is a volunteer effort. About the HTML docs - they are usually a little behind. If in doubt, check expat.h - or the source . And yes, Expat is good for wrappers. That is how I got into it (for Delphi). It supports basically everything needed to create a SAX2 wrapper with all SAX extensions. Entity reporting, however, has the same limitations as SAX, but we plan to find a way around it for a future release - so that Expat can provide everything needed for building a DOM (it *almost* does). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-12-16 11:18 Message: Logged In: NO The HTML documentation tells me something different. It indeed starts with an indication stating that these functions are useful when XML_Parse returns 0, but also that they are quote "the position reporting functions are useful outside of errors. " It only states that it can not be used inside a DTD. So the situation was not really clear. What was clear is that calling the line or column number function outside an handler before final resulted in a wrong answer, and as a bonus goofes up the further line and column number reports. Btw I still think, Expat is a really good XML library. It has a nice API, which makes it easy to create wrappers (I was working on an expat wrapper for OCaml) Here are the tests you requested: /* * Line and column numbers inside handlers test */ static void start_element_event_handler2(void *userData, const XML_Char *name, const XML_Char **attr) { CharData *storage = (CharData *) userData; char buffer[100]; sprintf(buffer, "<%s> at col:%d line:%d\n", name, XML_GetCurrentColumnNumber(parser), XML_GetCurrentLineNumber(parser)); CharData_AppendString(storage, buffer); } static void end_element_event_handler2(void *userData, const XML_Char *name) { CharData *storage = (CharData *) userData; char buffer[100]; sprintf(buffer, " at col:%d line:%d\n", name, XML_GetCurrentColumnNumber(parser), XML_GetCurrentLineNumber(parser)); CharData_AppendString(storage, buffer); } START_TEST(test_line_and_column_numbers_inside_handlers) { char *text = "\n" /* the unix idea of an end-of-line */ " \r\n" /* the windows of an end-of-line*/ " \r" /* also counts as an end-of-line */ " \n" " \n" " \n" " \n" ""; char *expected = " at col:0 line:1\n" " at col:2 line:2\n" " at col:4 line:3\n" " at col:8 line:3\n" " at col:2 line:4\n" " at col:2 line:5\n" " at col:4 line:6\n" " at col:8 line:6\n" " at col:2 line:7\n" " at col:0 line:8\n"; CharData storage; CharData_Init(&storage); XML_SetUserData(parser, &storage); XML_SetStartElementHandler(parser, start_element_event_handler2); XML_SetEndElementHandler(parser, end_element_event_handler2); if (XML_Parse(parser, text, strlen(text), 1) == XML_STATUS_ERROR) xml_failure(parser); CharData_CheckString(&storage, expected); } END_TEST START_TEST(test_line_number_after_error) { char *text = "\n" " \n" " "; /* missing */ int lineno; if (XML_Parse(parser, text, strlen(text), 0) != XML_STATUS_ERROR) fail("Expected a parse error"); lineno = XML_GetCurrentLineNumber(parser); if (lineno != 3) { char buffer[100]; sprintf(buffer, "expected 3 lines, saw %d", lineno); fail(buffer); } } END_TEST START_TEST(test_column_number_after_error) { char *text = "\n" " \n" " "; /* missing */ int colno; if (XML_Parse(parser, text, strlen(text), 0) != XML_STATUS_ERROR) fail("Expected a parse error"); colno = XML_GetCurrentColumnNumber(parser); if (colno != 4) { char buffer[100]; sprintf(buffer, "expected 4 columns, saw %d", colno); fail(buffer); } } END_TEST ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 22:49 Message: Logged In: YES user_id=290026 Just a comment: According to the documentation in expat.h, the line/column number functions should only be called when XML_Parse or XML_ParseBuffer return 0 (error) or from callback handlers. So, strictly speaking, this was not a bug. Another question - mostly for Fred: Why is it that line numbers are 1-based, and column numbers are 0-based? If we keep this behaviour then we should at least document it! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 15:05 Message: Logged In: YES user_id=290026 Great - I will apply a patch to CVS. Could you please subject it to a few tests for other situations, like: - calling the line/column functions after an error - calling them in a handler And report back here. If OK, this patch will go into the next release, which is coming soon. To Fred Drake: Fred, seems there is already a regression test case in the posts below. Would you please add it. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 14:07 Message: Logged In: YES user_id=350634 Thanks, this solved the problem. This was the first time I looked at the expat code, so I was a bit surprised to see that XML parsing is not as simple as I thought it would be. On the other hand, maybe the code needs to be refactored here and there too. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 11:34 Message: Logged In: YES user_id=290026 OK, I think this will be better. Same places as before, but instead of the previous statements insert these after XMLUpdatePosition: in XML_Parse(): positionPtr = end; in XML_ParseBuffer(): positionPtr = bufferPtr; Why is it not part of the scanning routines? I can only guess, since I didn't write it. I would say that a) it would make the code even more complicated b) it would likely not be faster ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 11:20 Message: Logged In: YES user_id=350634 No, this does not solve the problem. tests/runtests Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 make: *** [check] Error 1 Btw, this whole line/column counting seems to be one big side-effect ;) Why is it not implemented as part of the normal scanning routines. It seems like the buffer passed to XML_Parse will be checked (again) just to adjust the line and column numbers. During the "normal" scanning phase nothing is done to adjust the line and column numbers. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 01:54 Message: Logged In: YES user_id=290026 Try this - not tested: in XML_Parse(), right after XMLUpdatePosition, insert this line: eventPtr = eventEndPtr = end; and in XML_ParseBuffer, also right after XMLUpdatePosition, insert (as part of the conditional statement): eventPtr = eventEndPtr = bufferPtr; That should hopefully prevent double counting. Haven't really checked possible side-effects. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 00:48 Message: Logged In: YES user_id=350634 Hmm, It looks more like the line and column numbers are counted double outside the handlers. When I added this piece of code in front of the update routine the counting was correct. Looking at the source if found that outside the handers the update is called twice. It is first called in parse, and later when you call either XML_GetCurrentLineNumber, or XML_GetCurrentColumnNumber, because for some reason the eventPtr is set. (Which to me seems like this should only be the case in handlers, but I'm not sure) static void FASTCALL PREFIX(updatePosition)(const ENCODING *enc, const char *ptr, const char *end, POSITION *pos) { /* THIS IS NOT CORRECT * Yes, this is lame, but it helps to indicate a double * counting the newlines and column number problem */ static const char *s_ptr = NULL; static const char *s_end = NULL; if( (s_ptr == ptr) && (s_end == end)) /* we already counted this one */ return; s_ptr = ptr; s_end = end; /* The rest of the function */ ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-14 11:41 Message: Logged In: YES user_id=290026 I have looked a little closer. It seems the numbers are reported OK only if the parser is at the end or beginning of a token, but not in-between. Btw, the line/column number relates to the start of the token, as far as I can tell from the source. In your example, isFinal = 0, so the parser is in-between tokens and expects at least one more call to XML_Parse. I am not sure it is OK to call the line/column number functions in between calls to XML_Parse, since at this point the parser is in the middle of processing a token, while in the other situations (inside a handler, and when having an error) the parser knows exactly what the current token is or is not. One thing is sure: The documentation is not clear and sufficient. Also, from what I can tell, line numbers are 1-based and column numbers are 0-based. I don't think that is a good idea. It should probably be consistent with SAX, where both numbers are 1-based. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-14 11:22 Message: Logged In: YES user_id=350634 When I set a start element handler the line number reporting is fine, as long as no trailing newlines are inserted after the last tag. When instead of a start element handler a end element handler is set the line-number is always wrong. Inside the handlers the line-numbers are always ok. I did not check the behavoir for xml_parse errors, or the column number (yet). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-13 21:18 Message: Logged In: YES user_id=290026 Does this also happen in other situations? For instance: - inside a handler - when XML_Parse returns with an error? ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-13 06:01 Message: Logged In: YES user_id=350634 I forgot to add the tests: START_TEST(test_line_number_maas) { char *text = "\n" "\n" "\n"; int lineno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); lineno = XML_GetCurrentLineNumber(parser); if (lineno != 4) { char buffer[100]; sprintf(buffer, "expected 4 lines, saw %d", lineno); fail(buffer); } } END_TEST START_TEST(test_column_number_maas) { char *text = ""; int colno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); colno = XML_GetCurrentColumnNumber(parser); if (colno != 11) { char buffer[100]; sprintf(buffer, "expected 11 columns, saw %d", colno); fail(buffer); } } END_TEST Added to the test suite this resulted in: Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 From noreply at sourceforge.net Mon Dec 23 18:26:12 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Mon Dec 23 21:26:16 2002 Subject: [Expat-bugs] [ expat-Bugs-658080 ] Request a link on reentrancy Message-ID: Bugs item #658080, was opened at 2002-12-24 02:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=658080&group_id=10127 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Doug Ransom (dougransom) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Request a link on reentrancy Initial Comment: I have described a technique that can be used to make a reentrant parser in C or C++ with expat. http://www.codepedia.com/wiki/display.aspx?WikiID=1&pagename=thunks The technique is general, but I was inspired to write the article by the expat interface. I request a link to it so people know expat doesn't need to me modified to make a reentrant parser for mulitthreaded programming. They can also get rid of global variables in any expat parser, even if they are building a DOM. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=658080&group_id=10127 From noreply at sourceforge.net Mon Dec 30 11:50:43 2002 From: noreply at sourceforge.net (noreply@sourceforge.net) Date: Mon Dec 30 14:50:42 2002 Subject: [Expat-bugs] [ expat-Bugs-653180 ] problem with column and line numbers Message-ID: Bugs item #653180, was opened at 2002-12-13 05:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127 Category: None Group: Test Required >Status: Closed Resolution: Fixed Priority: 5 Submitted By: MM Zeeman (mmzeeman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: problem with column and line numbers Initial Comment: XML_GetCurrentColumnNumber returns 2 times the actual column number. The same holds for XML_GetCurrentLineNumber. The XML_GetCurrentByteIndex function returns the correct value. The expat version i'm using is: expat_1.95.5 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-30 14:50 Message: Logged In: YES user_id=3066 Tests added in tests/runtests.c revisions 1.40 and 1.41. Documentation clarified as part of doc/reference.html 1.37. Karl: Line numbers traditionally start at 1, while column numbers traditionally deal with insertion points (between characters). This is a somewhat annoying inconsistency, but historical in contexts well beyond Expat. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-16 12:33 Message: Logged In: YES user_id=290026 Thanks a lot for the test cases. We are really grateful when somebody helps out! After all, this is a volunteer effort. About the HTML docs - they are usually a little behind. If in doubt, check expat.h - or the source . And yes, Expat is good for wrappers. That is how I got into it (for Delphi). It supports basically everything needed to create a SAX2 wrapper with all SAX extensions. Entity reporting, however, has the same limitations as SAX, but we plan to find a way around it for a future release - so that Expat can provide everything needed for building a DOM (it *almost* does). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-12-16 11:18 Message: Logged In: NO The HTML documentation tells me something different. It indeed starts with an indication stating that these functions are useful when XML_Parse returns 0, but also that they are quote "the position reporting functions are useful outside of errors. " It only states that it can not be used inside a DTD. So the situation was not really clear. What was clear is that calling the line or column number function outside an handler before final resulted in a wrong answer, and as a bonus goofes up the further line and column number reports. Btw I still think, Expat is a really good XML library. It has a nice API, which makes it easy to create wrappers (I was working on an expat wrapper for OCaml) Here are the tests you requested: /* * Line and column numbers inside handlers test */ static void start_element_event_handler2(void *userData, const XML_Char *name, const XML_Char **attr) { CharData *storage = (CharData *) userData; char buffer[100]; sprintf(buffer, "<%s> at col:%d line:%d\n", name, XML_GetCurrentColumnNumber(parser), XML_GetCurrentLineNumber(parser)); CharData_AppendString(storage, buffer); } static void end_element_event_handler2(void *userData, const XML_Char *name) { CharData *storage = (CharData *) userData; char buffer[100]; sprintf(buffer, " at col:%d line:%d\n", name, XML_GetCurrentColumnNumber(parser), XML_GetCurrentLineNumber(parser)); CharData_AppendString(storage, buffer); } START_TEST(test_line_and_column_numbers_inside_handlers) { char *text = "\n" /* the unix idea of an end-of-line */ " \r\n" /* the windows of an end-of-line*/ " \r" /* also counts as an end-of-line */ " \n" " \n" " \n" " \n" ""; char *expected = " at col:0 line:1\n" " at col:2 line:2\n" " at col:4 line:3\n" " at col:8 line:3\n" " at col:2 line:4\n" " at col:2 line:5\n" " at col:4 line:6\n" " at col:8 line:6\n" " at col:2 line:7\n" " at col:0 line:8\n"; CharData storage; CharData_Init(&storage); XML_SetUserData(parser, &storage); XML_SetStartElementHandler(parser, start_element_event_handler2); XML_SetEndElementHandler(parser, end_element_event_handler2); if (XML_Parse(parser, text, strlen(text), 1) == XML_STATUS_ERROR) xml_failure(parser); CharData_CheckString(&storage, expected); } END_TEST START_TEST(test_line_number_after_error) { char *text = "\n" " \n" " "; /* missing */ int lineno; if (XML_Parse(parser, text, strlen(text), 0) != XML_STATUS_ERROR) fail("Expected a parse error"); lineno = XML_GetCurrentLineNumber(parser); if (lineno != 3) { char buffer[100]; sprintf(buffer, "expected 3 lines, saw %d", lineno); fail(buffer); } } END_TEST START_TEST(test_column_number_after_error) { char *text = "\n" " \n" " "; /* missing */ int colno; if (XML_Parse(parser, text, strlen(text), 0) != XML_STATUS_ERROR) fail("Expected a parse error"); colno = XML_GetCurrentColumnNumber(parser); if (colno != 4) { char buffer[100]; sprintf(buffer, "expected 4 columns, saw %d", colno); fail(buffer); } } END_TEST ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 22:49 Message: Logged In: YES user_id=290026 Just a comment: According to the documentation in expat.h, the line/column number functions should only be called when XML_Parse or XML_ParseBuffer return 0 (error) or from callback handlers. So, strictly speaking, this was not a bug. Another question - mostly for Fred: Why is it that line numbers are 1-based, and column numbers are 0-based? If we keep this behaviour then we should at least document it! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 15:05 Message: Logged In: YES user_id=290026 Great - I will apply a patch to CVS. Could you please subject it to a few tests for other situations, like: - calling the line/column functions after an error - calling them in a handler And report back here. If OK, this patch will go into the next release, which is coming soon. To Fred Drake: Fred, seems there is already a regression test case in the posts below. Would you please add it. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 14:07 Message: Logged In: YES user_id=350634 Thanks, this solved the problem. This was the first time I looked at the expat code, so I was a bit surprised to see that XML parsing is not as simple as I thought it would be. On the other hand, maybe the code needs to be refactored here and there too. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 11:34 Message: Logged In: YES user_id=290026 OK, I think this will be better. Same places as before, but instead of the previous statements insert these after XMLUpdatePosition: in XML_Parse(): positionPtr = end; in XML_ParseBuffer(): positionPtr = bufferPtr; Why is it not part of the scanning routines? I can only guess, since I didn't write it. I would say that a) it would make the code even more complicated b) it would likely not be faster ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 11:20 Message: Logged In: YES user_id=350634 No, this does not solve the problem. tests/runtests Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 make: *** [check] Error 1 Btw, this whole line/column counting seems to be one big side-effect ;) Why is it not implemented as part of the normal scanning routines. It seems like the buffer passed to XML_Parse will be checked (again) just to adjust the line and column numbers. During the "normal" scanning phase nothing is done to adjust the line and column numbers. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-15 01:54 Message: Logged In: YES user_id=290026 Try this - not tested: in XML_Parse(), right after XMLUpdatePosition, insert this line: eventPtr = eventEndPtr = end; and in XML_ParseBuffer, also right after XMLUpdatePosition, insert (as part of the conditional statement): eventPtr = eventEndPtr = bufferPtr; That should hopefully prevent double counting. Haven't really checked possible side-effects. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-15 00:48 Message: Logged In: YES user_id=350634 Hmm, It looks more like the line and column numbers are counted double outside the handlers. When I added this piece of code in front of the update routine the counting was correct. Looking at the source if found that outside the handers the update is called twice. It is first called in parse, and later when you call either XML_GetCurrentLineNumber, or XML_GetCurrentColumnNumber, because for some reason the eventPtr is set. (Which to me seems like this should only be the case in handlers, but I'm not sure) static void FASTCALL PREFIX(updatePosition)(const ENCODING *enc, const char *ptr, const char *end, POSITION *pos) { /* THIS IS NOT CORRECT * Yes, this is lame, but it helps to indicate a double * counting the newlines and column number problem */ static const char *s_ptr = NULL; static const char *s_end = NULL; if( (s_ptr == ptr) && (s_end == end)) /* we already counted this one */ return; s_ptr = ptr; s_end = end; /* The rest of the function */ ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-14 11:41 Message: Logged In: YES user_id=290026 I have looked a little closer. It seems the numbers are reported OK only if the parser is at the end or beginning of a token, but not in-between. Btw, the line/column number relates to the start of the token, as far as I can tell from the source. In your example, isFinal = 0, so the parser is in-between tokens and expects at least one more call to XML_Parse. I am not sure it is OK to call the line/column number functions in between calls to XML_Parse, since at this point the parser is in the middle of processing a token, while in the other situations (inside a handler, and when having an error) the parser knows exactly what the current token is or is not. One thing is sure: The documentation is not clear and sufficient. Also, from what I can tell, line numbers are 1-based and column numbers are 0-based. I don't think that is a good idea. It should probably be consistent with SAX, where both numbers are 1-based. ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-14 11:22 Message: Logged In: YES user_id=350634 When I set a start element handler the line number reporting is fine, as long as no trailing newlines are inserted after the last tag. When instead of a start element handler a end element handler is set the line-number is always wrong. Inside the handlers the line-numbers are always ok. I did not check the behavoir for xml_parse errors, or the column number (yet). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-12-13 21:18 Message: Logged In: YES user_id=290026 Does this also happen in other situations? For instance: - inside a handler - when XML_Parse returns with an error? ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2002-12-13 06:01 Message: Logged In: YES user_id=350634 I forgot to add the tests: START_TEST(test_line_number_maas) { char *text = "\n" "\n" "\n"; int lineno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); lineno = XML_GetCurrentLineNumber(parser); if (lineno != 4) { char buffer[100]; sprintf(buffer, "expected 4 lines, saw %d", lineno); fail(buffer); } } END_TEST START_TEST(test_column_number_maas) { char *text = ""; int colno; if (XML_Parse(parser, text, strlen(text), 0) == XML_STATUS_ERROR) xml_failure(parser); colno = XML_GetCurrentColumnNumber(parser); if (colno != 11) { char buffer[100]; sprintf(buffer, "expected 11 columns, saw %d", colno); fail(buffer); } } END_TEST Added to the test suite this resulted in: Running suite(s): basic 93%: Checks: 31, Failures: 2, Errors: 0 tests/runtests.c:342:F:basic tests: expected 4 lines, saw 7 tests/runtests.c:357:F:basic tests: expected 11 columns, saw 22 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=653180&group_id=10127