From fcadili at ngi.it  Tue Nov  1 16:39:21 2005
From: fcadili at ngi.it (Francesco cadili)
Date: Tue, 1 Nov 2005 16:39:21 +0100
Subject: [Expat-bugs] Bug on MacOSX 10.4
Message-ID: <a06230900bf8d3b0e92f3@[192.168.1.7]>

I have tried to compile expat-1.95.8 with MacOSX 10.4 but I obtained 
the following error while executing:

	$./configure --prefix=/Volumes/Ext/OpenSource/expat/install-1.95.8
	...snip
	mv: Makefile: set owner/group (was: 501/0): Operation not permitted
	config.status: creating expat_config.h
	config.status: expat_config.h is unchanged

with my user fcadili (not superuser)

The problem was inside config.status the at the instruction
	mv $tmp/out $ac_file

Replacing this instruction with:
	cat $tmp/out > $ac_file
	rm -rf 	$tmp/out

The error disappear.

Regards,
	Francesco Cadili

From monkeonman at gmail.com  Thu Nov  3 12:30:44 2005
From: monkeonman at gmail.com (Dan)
Date: Thu, 3 Nov 2005 11:30:44 +0000
Subject: [Expat-bugs] Dr Watson
Message-ID: <2808c5260511030330j75c5e97atdbfc8f0e6c2fd722@mail.gmail.com>

Hi,

I'm getting intermittent crashes on the line:
table->v[i] = calloc(1, createSize);

This can be found in lookup().

I'm also getting crashes on some other lines, but the one above is the
most common...

I'm not really sure what version of the expat library I'm running
(very useful I know), but does anyone recognise this as an issue that
has been reported/fixed?  Also, if anyone could tell me how to
identify what version I'm running, that would also be appreciated!!

Cheers

Dan

From noreply at sourceforge.net  Wed Nov 16 10:24:03 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 Nov 2005 01:24:03 -0800
Subject: [Expat-bugs] [ expat-Bugs-1357962 ] Parser error
Message-ID: <E1EcJWN-0003MY-LT@sc8-sf-web4.sourceforge.net>

Bugs item #1357962, was opened at 2005-11-16 01:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1357962&group_id=10127

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parser error

Initial Comment:
Xml Parser throws error for the following xml attribute:
<Reference
      Name = "WindowsControlLibrary2"
      Path = "f:\kri&raj\WindowsControlLibrary2.dll"
/>

In the above scenario, the value of the Path attribute
is a valid path. But xml parser throws error when it
hits &. Is this behaviour correct?


Submitted by:
krithiga.selvaraj at gmail.com

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

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

From noreply at sourceforge.net  Thu Nov 24 15:11:39 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 Nov 2005 06:11:39 -0800
Subject: [Expat-bugs] [ expat-Bugs-1357962 ] Parser error
Message-ID: <E1EfHp5-0002PM-JE@sc8-sf-web2.sourceforge.net>

Bugs item #1357962, was opened at 2005-11-16 04:24
Message generated for change (Settings changed) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1357962&group_id=10127

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parser error

Initial Comment:
Xml Parser throws error for the following xml attribute:
<Reference
      Name = "WindowsControlLibrary2"
      Path = "f:\kri&raj\WindowsControlLibrary2.dll"
/>

In the above scenario, the value of the Path attribute
is a valid path. But xml parser throws error when it
hits &. Is this behaviour correct?


Submitted by:
krithiga.selvaraj at gmail.com

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-24 09:11

Message:
Logged In: YES 
user_id=290026

The & must be escaped with &amp;.
Closed, not a bug.

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

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

From noreply at sourceforge.net  Thu Nov 24 15:16:32 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 Nov 2005 06:16:32 -0800
Subject: [Expat-bugs] [ expat-Bugs-1271642 ] ill-formed output for `xmlwf -c
	-d` on ISO-8859-1
Message-ID: <E1EfHto-0002Uq-B4@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Test Required
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ill-formed output for `xmlwf -c -d` on ISO-8859-1

Initial Comment:
If I run:
   xmlwf -c -d /tmp bug.xml

with bug.xml containing:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<e a="A&eacute;">123</e>
</html>

then the result is:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
&eacute;123</e>
</html>

The start tag for e is lost and the entity ref in the
attribute is copied.

Note that this bug does not happen if the encoding is
UTF-8 or US-ASCII.

Bug reproduced by a third party, see:
http://mail.libexpat.org/pipermail/expat-discuss/2005-August/001880.html



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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-24 09:16

Message:
Logged In: YES 
user_id=290026

Fixed in xmlparse.c rev. 1.149.
Needs testing.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-08-25 11:46

Message:
Logged In: YES 
user_id=290026

It appears this is caused by an inapproriate call to the default 
handler in appendAttributeValue(). Removing this call seems 
to fix the problem. Please apply and test the patch attached 
as file patch1.diff.



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

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

From noreply at sourceforge.net  Thu Nov 24 15:18:12 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 Nov 2005 06:18:12 -0800
Subject: [Expat-bugs] [ expat-Bugs-1241534 ] Support for special character
	set
Message-ID: <E1EfHvQ-0002X2-BG@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Feature Request
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Sukender (sukender)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Support for special character set

Initial Comment:
I'm not sure, but I think some charcters produce
errors. If you try

<!-- Un commentaire en fan?ais avec des accents : ???? -->

you'll have a parsing error. Try a word with "?" and
then replace it by "e" : the error disapear. It's
perhaps a problem with my program but it's a strange
behaviour !

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-24 09:18

Message:
Logged In: YES 
user_id=290026

Rejected due to lack of feedback from original reporter.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2005-08-21 15:30

Message:
Logged In: NO 

I have the same issue. The file is encoded with UTF-8 and I've 
forced the encoding using others like US-Ascii and ISO-899..

Also when I manually escape the character to &233; 
(example) it always unescapes to UTF-8 it looks like. 

My work around was simply to remove all high character 
values before a parse. 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-08-19 08:55

Message:
Logged In: YES 
user_id=290026

What encoding do you use, and what encoding is specified
in the input file?

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

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

From noreply at sourceforge.net  Sun Nov 27 19:45:22 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 Nov 2005 10:45:22 -0800
Subject: [Expat-bugs] [ expat-Bugs-1285336 ] Build from IIDE Visual 7.0 7.1
Message-ID: <E1EgRWc-0007hd-Is@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build control
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Build from IIDE Visual 7.0 7.1

Initial Comment:
1) In IDE  project elements sample is incorrectly 
constructed as DLL.
2) for subproject expatw_static
 In Project/Properties/ C++/ Preprocessor/Preprocessor 
Definitions 
XML_UNICODE_WCHAR_T is not set.
As a result static library for unicode does not buit 
properly
 

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 13:45

Message:
Logged In: YES 
user_id=290026

Closed due to lack of follow-up by original poster.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-09-08 18:38

Message:
Logged In: YES 
user_id=290026

The actual project files in CVS are for VS 6.0.
I checked - opening the expat workspace in VS 6.0 - and the
project settings are correct there.

I therefore assume that the import into VS 7 was faulty.
Try refreshing from CVS and re-importing the workspace.

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

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

From noreply at sourceforge.net  Sun Nov 27 20:22:59 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 Nov 2005 11:22:59 -0800
Subject: [Expat-bugs] [ expat-Bugs-1284386 ] Byte count in large XML files
	fails
Message-ID: <E1EgS71-000667-87@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rolf Ade (pointsman)
>Assigned to: Karl Waclawek (kwaclaw)
Summary: Byte count in large XML files fails

Initial Comment:

XML_GetCurrentByteIndex(XML_Parser parser) returns a
long, which is at least on the most 32 bit Systems 32
bit long. That means, for XML input larger than 2 GByte
file size, XML_GetCurrentByteIndex() returns does not
return the right number.

Sure, such big XML files will be parsed in chunks, so
it is possbile, to keep track about the nr of overflows
by self, but come on.

It's surely a limbo dance by its own to introcude long
long in a source, so portable as expat, but that would
be it.

If you switch to long long if avaliable for this,
please consider also XML_GetCurrentLineNumber() and
XML_GetCurrentColumnNumber(). They return an int, which
is on most 32-byte systems 2 Gig. Though, I'm not
stumbled over this two limits in real life, as I in
fact did with XML_GetCurrentByteIndex(). 

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 14:22

Message:
Logged In: YES 
user_id=290026

Rolf,

should the type be 64 bit integer on all platforms,
or 32bit on 32bit platforms and 64bit on 64bit platforms?
I think we are talking about m_parseEndByteIndex,
POSITION.lineNumber and POSITION.columnNumber.

Options could be size_t, ptrdiff_t.
MS VC++ 6.0 does not know about long long, but it knows
about __int64. Is there an ANSI definition for 64 bit ints?

What do you suggest that works on all platforms?

Karl





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

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

From noreply at sourceforge.net  Sun Nov 27 20:24:29 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 Nov 2005 11:24:29 -0800
Subject: [Expat-bugs] [ expat-Bugs-1241242 ] v1.95.8: expat_external.h does
	not get installed
Message-ID: <E1EgS8T-0008HK-By@sc8-sf-web1.sourceforge.net>

Bugs item #1241242, was opened at 2005-07-19 18:59
Message generated for change (Comment added) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1241242&group_id=10127

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build control
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: v1.95.8: expat_external.h does not get installed

Initial Comment:
command executed during make install (from "make" 
output):
conftools/install-sh -c -m 
644 ./lib/expat.h ./lib/expat_external.h /apps/apache/v0.4
.5_20050518-1531/usrlocal/include

Info in the first few lines of install-sh mentions that "It 
can only install one file at a time."

File expat_external.h is not found in the destination 
include dir.

Following changes to Makefile seem to fix (relevant 
lines quoted):
...
APIHEADER = $(srcdir)/lib/expat.h
APIHEADER2 = $(srcdir)/lib/expat_external.h
...
        $(INSTALL_DATA) $(APIHEADER) $(includedir)
        $(INSTALL_DATA) $(APIHEADER2) $(includedir)
...
        rm -f $(includedir)/$(APIHEADER) $(includedir)/
$(APIHEADER2)
...


Build environment: Solaris 8
GCC 3.4.2
GNU make 3.80

Regards,
Lieven DeBock
ldb125 \a/t\ gmail /d\o/t\ com


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 14:24

Message:
Logged In: YES 
user_id=290026

Closed - duplicate of issue #1177957.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2005-07-19 21:06

Message:
Logged In: NO 

Please disregard - duplicates 1177957
Lieven DeBock

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

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

From noreply at sourceforge.net  Sun Nov 27 20:26:44 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 Nov 2005 11:26:44 -0800
Subject: [Expat-bugs] [ expat-Bugs-1237648 ] detected recursion whilst
	expanding macro "XML_STATUS_ERROR"
Message-ID: <E1EgSAe-0006BQ-G0@sc8-sf-web4.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build control
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: detected recursion whilst expanding macro "XML_STATUS_ERROR"

Initial Comment:
Hi all, 

I got a problem in installing expat 1.95.7 on Mac os X (darwin). 

./configure run ok.

make gave one error:

/bin/sh ./libtool --silent --mode=compile cc -g -O2 -Wall -Wmissing-
prototypes -Wstrict-prototypes -fexceptions -
DHAVE_EXPAT_CONFIG_H  -traditional-cpp -I./lib -I. -o lib/
xmlparse.lo -c lib/xmlparse.c
lib/xmlparse.c:918: error: detected recursion whilst expanding 
macro "XML_STATUS_ERROR"
lib/xmlparse.c:924: error: detected recursion whilst expanding 
macro "XML_STATUS_ERROR"
lib/xmlparse.c:926: error: detected recursion whilst expanding 
macro "XML_STATUS_OK"
lib/xmlparse.c:1157: error: detected recursion whilst expanding 
macro "XML_STATUS_ERROR"
lib/xmlparse.c:1162: error: detected recursion whilst expanding 
macro "XML_STATUS_OK"
lib/xmlparse.c:1404: error: detected recursion whilst expanding 
macro "XML_STATUS_OK"
lib/xmlparse.c:1408: error: detected recursion whilst expanding 
macro "XML_STATUS_OK"
lib/xmlparse.c:1411: error: detected recursion whilst expanding 
macro "XML_STATUS_ERROR"
lib/xmlparse.c:1466: error: detected recursion whilst expanding 
macro "XML_STATUS_ERROR"
lib/xmlparse.c:1488: error: detected recursion whilst expanding 
macro "XML_STATUS_OK"
lib/xmlparse.c:1493: error: detected recursion whilst expanding 
macro "XML_STATUS_ERROR"
make: *** [lib/xmlparse.lo] Error 1

can someone give me a help. Thanks very much. 

chenhong

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 14:26

Message:
Logged In: YES 
user_id=290026

Closed due to lack of follow-up by poster.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-07-16 04:20

Message:
Logged In: YES 
user_id=290026

Which compiler are you using?
Try to update the compiler, if possible.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2005-07-15 12:59

Message:
Logged In: NO 

I actually tried with expat1.95.8
Still have the same problems

thanks




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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-07-15 12:57

Message:
Logged In: YES 
user_id=290026

Looks like a compiler issue.
Check out bug # 1171968.

Switch to gcc, if possible.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2005-07-15 12:12

Message:
Logged In: NO 

I actually tried with expat1.95.8
Still have the same problems

thanks




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

Comment By: Nobody/Anonymous (nobody)
Date: 2005-07-15 12:06

Message:
Logged In: NO 

I got the same exact problem when building on OPTERON
Any ideas will be welcome
thanks

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-07-13 15:02

Message:
Logged In: YES 
user_id=290026

Does it work allright with Expat 1.95.8?

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

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

From noreply at sourceforge.net  Sun Nov 27 20:28:35 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 Nov 2005 11:28:35 -0800
Subject: [Expat-bugs] [ expat-Bugs-1236372 ] v1.95.8 compile warnings
	lib/xmlparse.c
Message-ID: <E1EgSCR-0006lt-NG@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: v1.95.8 compile warnings lib/xmlparse.c

Initial Comment:
On Solaris 9 Sparc, using Sun CC the following warnings appear when doing a 'make' on expat v1.95.8

/bin/bash ./libtool --silent --mode=compile cc -g -DHAVE_EXPAT_CONFIG_H   -I./li
b -I. -o lib/xmlparse.lo -c lib/xmlparse.c
"lib/xmlparse.c", line 1572: warning: enum type mismatch: op "="
"lib/xmlparse.c", line 1578: warning: enum type mismatch: op "="
"lib/xmlparse.c", line 1586: warning: enum type mismatch: op "="
"lib/xmlparse.c", line 1719: warning: enum type mismatch: op "="
"lib/xmlparse.c", line 1725: warning: enum type mismatch: op "="
"lib/xmlparse.c", line 1733: warning: enum type mismatch: op "="

The following changes appear to fix the problem
============================================
*** xmlparse.c.orig     Thu Jul 22 22:02:41 2004
--- xmlparse.c  Wed Jun  8 14:41:53 2005
***************
*** 1539,1545 ****
  XML_ParseBuffer(XML_Parser parser, int len, int isFinal)
  {
    const char *start;
!   enum XML_Error result = XML_STATUS_OK;
  
    switch (parsing) {
    case XML_SUSPENDED:
--- 1539,1545 ----
  XML_ParseBuffer(XML_Parser parser, int len, int isFinal)
  {
    const char *start;
!   enum XML_Status result = XML_STATUS_OK;
  
    switch (parsing) {
    case XML_SUSPENDED:
***************
*** 1698,1704 ****
  enum XML_Status XMLCALL
  XML_ResumeParser(XML_Parser parser)
  {
!   enum XML_Error result = XML_STATUS_OK;
  
    if (parsing != XML_SUSPENDED) {
      errorCode = XML_ERROR_NOT_SUSPENDED;
--- 1698,1704 ----
  enum XML_Status XMLCALL
  XML_ResumeParser(XML_Parser parser)
  {
!   enum XML_Status result = XML_STATUS_OK;
  
    if (parsing != XML_SUSPENDED) {
      errorCode = XML_ERROR_NOT_SUSPENDED;
============================================

Regards,
Todd Olson
tco2  -a--t-  cornell  -d--o--t-  edu


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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 14:28

Message:
Logged In: YES 
user_id=290026

Closed, as it seems to be fixed in CVS and there was no
follow-up by the popster.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-07-12 05:25

Message:
Logged In: YES 
user_id=290026

I believe this has been fixed in CVS a while ago.
Please check it out.

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

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

From noreply at sourceforge.net  Sun Nov 27 20:30:20 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 Nov 2005 11:30:20 -0800
Subject: [Expat-bugs] [ expat-Bugs-1230954 ] "make all" fails for libexpat
Message-ID: <E1EgSE8-0006FU-4P@sc8-sf-web4.sourceforge.net>

Bugs item #1230954, was opened at 2005-07-01 09:53
Message generated for change (Settings changed) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1230954&group_id=10127

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build control
Group: Platform Specific
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: ken klein (kklein9)
Assigned to: Greg Stein (gstein)
Summary: "make all" fails for libexpat

Initial Comment:
aix 5.3 ml 02 power 5 on pSeries p570 partition.


The complete output from the make all failure is below:

root at f2sys1
(2133)[/home/ken/expat/expat-1.95.8]# make all 
        /bin/sh ./libtool --silent --mode=compile gcc
-g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes
-fexceptions -DHAVE_EXPAT_CONF
IG_H   -I./lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c
        /bin/sh ./libtool --silent --mode=compile gcc
-g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes
-fexceptions -DHAVE_EXPAT_CONF
IG_H   -I./lib -I. -o lib/xmltok.lo -c lib/xmltok.c
        /bin/sh ./libtool --silent --mode=compile gcc
-g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes
-fexceptions -DHAVE_EXPAT_CONF
IG_H   -I./lib -I. -o lib/xmlrole.lo -c lib/xmlrole.c
        /bin/sh ./libtool --silent --mode=link gcc -g
-O2 -Wall -Wmissing-prototypes -Wstrict-prototypes
-fexceptions -DHAVE_EXPAT_CONFIG_
H   -I./lib -I. -no-undefined -version-info 5:0:5
-rpath /usr/local/lib  -o libexpat.la lib/xmlparse.lo
lib/xmltok.lo lib/xmlrole.lo
ld: 0711-415 WARNING: Symbol
_GLOBAL__F_XML_ParserCreate is already exported.
ld: 0711-415 WARNING: Symbol _GLOBAL__F_XmlUtf8Encode
is already exported.
ld: 0711-415 WARNING: Symbol
_GLOBAL__F_XmlPrologStateInit is already exported.
        gcc -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H
  -I./lib -I. -o xmlwf/xmlwf.o -c xml
wf/xmlwf.c
        gcc -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H
  -I./lib -I. -o xmlwf/xmlfile.o -c x
mlwf/xmlfile.c
        gcc -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H
  -I./lib -I. -o xmlwf/codepage.o -c 
xmlwf/codepage.c
        gcc -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H
  -I./lib -I. -o xmlwf/readfilemap.o 
-c xmlwf/readfilemap.c
        /bin/sh ./libtool --silent --mode=link gcc -g
-O2 -Wall -Wmissing-prototypes -Wstrict-prototypes
-fexceptions -DHAVE_EXPAT_CONFIG_
H   -I./lib -I.  -o xmlwf/xmlwf xmlwf/xmlwf.o
xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/readfilemap.o
libexpat.la
        gcc -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H
  -I./lib -I. -o examples/elements.o 
-c examples/elements.c
        /bin/sh ./libtool --silent --mode=link gcc -g
-O2 -Wall -Wmissing-prototypes -Wstrict-prototypes
-fexceptions -DHAVE_EXPAT_CONFIG_
H   -I./lib -I.  -o examples/elements  libexpat.la
ld: 0711-317 ERROR: Undefined symbol: .main
ld: 0711-345 Use the -bloadmap or -bnoquiet option to
obtain more information.
collect2: ld returned 8 exit status
make: 1254-004 The error code from the last command is 1.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 14:30

Message:
Logged In: YES 
user_id=290026

Closed - duplicate of #1230582.

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

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

From noreply at sourceforge.net  Sun Nov 27 20:31:41 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 Nov 2005 11:31:41 -0800
Subject: [Expat-bugs] [ expat-Bugs-1220249 ] Build on x86em (windows ce)
Message-ID: <E1EgSFR-0006GX-Sq@sc8-sf-web4.sourceforge.net>

Bugs item #1220249, was opened at 2005-06-14 06:12
Message generated for change (Settings changed) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1220249&group_id=10127

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Build on x86em (windows ce)

Initial Comment:
I had to make the definition of
XML_Memory_Handline_Suite this:

typedef struct {
  void* (XMLCALL *malloc_fcn)(size_t size);
  void* (XMLCALL *realloc_fcn)(void *ptr, size_t size);
  void  (XMLCALL *free_fcn)(void *ptr);
} XML_Memory_Handling_Suite;

to be able to compile for emulator. I'm using eMVC 3.1

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 14:31

Message:
Logged In: YES 
user_id=290026

Closed due to lack of follow-up by the poster.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-06-15 08:51

Message:
Logged In: YES 
user_id=290026

I think this depends on what the default calling convention is.
The memory handling function pointers must be assignment
compatible with the built-in memory handling functions.
This usually works with the default calling convention.

The problem is, if you change the definition of XML_CALL,
the calling convention for the built-in memory handlers
will not change and you get a mismatch.

Why don't you try changing your default calling convention
instead?
This is a project setting, I believe.

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

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

From noreply at sourceforge.net  Sun Nov 27 20:46:15 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 Nov 2005 11:46:15 -0800
Subject: [Expat-bugs] [ expat-Bugs-1177957 ] Makefile.in doesn't install
	expat_external.h on SGI
Message-ID: <E1EgSTX-0008KW-K1@sc8-sf-web3.sourceforge.net>

Bugs item #1177957, was opened at 2005-04-06 13:40
Message generated for change (Comment added) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1177957&group_id=10127

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build control
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: Makefile.in doesn't install expat_external.h on SGI

Initial Comment:
(Submitted by Mark Zieg, mark at zieg.com)

The conftools/install-sh script provided clearly
specifies that it can only install one file at a time.
 However, there are TWO headers listed in APIHEADER;
ergo, the second one gets dropped.

The following patch fixes Makefile.in:

--- Makefile.in 2004-05-07 16:00:48.000000000 -0400
+++ /home/ziegm/save/Makefile.in        2005-04-06
13:33:57.537788960 -0400
@@ -41,7 +41,8 @@
 mkinstalldirs = $(SHELL)
$(top_srcdir)/conftools/mkinstalldirs

 MANFILE = $(srcdir)/doc/xmlwf.1
-APIHEADER = $(srcdir)/lib/expat.h
$(srcdir)/lib/expat_external.h
+APIHEADER1 = $(srcdir)/lib/expat.h
+APIHEADER2 = $(srcdir)/lib/expat_external.h
 LIBRARY = libexpat.la


@@ -80,7 +81,8 @@
 installlib: $(LIBRARY) $(APIHEADER)
        $(mkinstalldirs) $(libdir) $(includedir)
        $(LIBTOOL) --mode=install $(INSTALL) $(LIBRARY)
$(libdir)/$(LIBRARY)
-       $(INSTALL_DATA) $(APIHEADER) $(includedir)
+       $(INSTALL_DATA) $(APIHEADER1) $(includedir)
+       $(INSTALL_DATA) $(APIHEADER2) $(includedir)

 uninstall: uninstalllib
        $(LIBTOOL) --mode=uninstall rm -f $(bindir)/xmlwf



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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 14:46

Message:
Logged In: YES 
user_id=290026

Closed due to lack of follow-up by poster.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2005-05-11 00:14

Message:
Logged In: NO 

Same on Sun

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-04-06 13:52

Message:
Logged In: YES 
user_id=290026

I think this has been resolved in CVS.
Please check and confirm, so that we can close this issue.

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

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

From noreply at sourceforge.net  Sun Nov 27 20:49:50 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 Nov 2005 11:49:50 -0800
Subject: [Expat-bugs] [ expat-Bugs-1156398 ] XML_UseForeignDTD forces
	incorrect WF checking
Message-ID: <E1EgSX0-0000Br-UE@sc8-sf-web1.sourceforge.net>

Bugs item #1156398, was opened at 2005-03-03 21:19
Message generated for change (Settings changed) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1156398&group_id=10127

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
>Group: Test Required
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Karl Waclawek (kwaclaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: XML_UseForeignDTD forces incorrect WF checking

Initial Comment:

When Expat calls the externalEntityRefHandler within
the prolog,
then it concludes that there must be an external
subset, as there
was an external identifier encountered.
This information influences how the WFC: Entity Declared
is checked.

However, when Expat calls the externalEntityRefHandler
in order
to allow the application to supply an external subset
when there
was none, then Expat should not make this assumption unless
an actual subset has been processed, as indicated by the
dtd->paramEntityRead flag.

The attached patch fixes this.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-06-20 09:57

Message:
Logged In: YES 
user_id=290026

Forgot to mention: This patch was applied in xmlparse.c rev.
1.147.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-03-03 23:18

Message:
Logged In: YES 
user_id=290026

We could use the following document for a test case::

<!DOCTYPE root 
[
<!ELEMENT root (#PCDATA)>
<!ATTLIST root att CDATA #IMPLIED>
<!ENTITY aaa "aString">
]>
<root att="&aAa;">reference doesn't match delaration</root>

This document violates WFC: Entity Declared and Expat must
return an error. However, if this document had an external
subset
then WFC: Entity Declared would not apply.
Now, if one calls XML_UseForeignDTD() at the start of parsing
the document above, then Expat 1.95.8 will accept the document,
which is not correct. The patched version of Expat will return
an error as it should.

Assigned to Fred for testing.
I really want this to be in release 2.0, as it improves the
conformance against the XML_Test-Suite.

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

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

From noreply at sourceforge.net  Sun Nov 27 21:22:31 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 Nov 2005 12:22:31 -0800
Subject: [Expat-bugs] [ expat-Bugs-1284386 ] Byte count in large XML files
	fails
Message-ID: <E1EgT2d-00044n-9g@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rolf Ade (pointsman)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Byte count in large XML files fails

Initial Comment:

XML_GetCurrentByteIndex(XML_Parser parser) returns a
long, which is at least on the most 32 bit Systems 32
bit long. That means, for XML input larger than 2 GByte
file size, XML_GetCurrentByteIndex() returns does not
return the right number.

Sure, such big XML files will be parsed in chunks, so
it is possbile, to keep track about the nr of overflows
by self, but come on.

It's surely a limbo dance by its own to introcude long
long in a source, so portable as expat, but that would
be it.

If you switch to long long if avaliable for this,
please consider also XML_GetCurrentLineNumber() and
XML_GetCurrentColumnNumber(). They return an int, which
is on most 32-byte systems 2 Gig. Though, I'm not
stumbled over this two limits in real life, as I in
fact did with XML_GetCurrentByteIndex(). 

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

>Comment By: Rolf Ade (pointsman)
Date: 2005-11-27 20:22

Message:
Logged In: YES 
user_id=13222

Karl,

Most reasonable 32bit platforms have support for file sizes
> 2 GB these days even on 32. It was in fact a 32bit
platform, at which I stumbled over the problem. That for
your easy question.

Much harder is how to slove this in a portable way. I'm
afraid that may need platform depending #defines (with
fallback to long).

I'll go out digging what other portable software does in
this case and will come back with a more concrete proposal.

rolf




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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 19:22

Message:
Logged In: YES 
user_id=290026

Rolf,

should the type be 64 bit integer on all platforms,
or 32bit on 32bit platforms and 64bit on 64bit platforms?
I think we are talking about m_parseEndByteIndex,
POSITION.lineNumber and POSITION.columnNumber.

Options could be size_t, ptrdiff_t.
MS VC++ 6.0 does not know about long long, but it knows
about __int64. Is there an ANSI definition for 64 bit ints?

What do you suggest that works on all platforms?

Karl





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

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

From noreply at sourceforge.net  Sun Nov 27 21:31:15 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 Nov 2005 12:31:15 -0800
Subject: [Expat-bugs] [ expat-Bugs-1284386 ] Byte count in large XML files
	fails
Message-ID: <E1EgTB5-0000wm-Us@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rolf Ade (pointsman)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Byte count in large XML files fails

Initial Comment:

XML_GetCurrentByteIndex(XML_Parser parser) returns a
long, which is at least on the most 32 bit Systems 32
bit long. That means, for XML input larger than 2 GByte
file size, XML_GetCurrentByteIndex() returns does not
return the right number.

Sure, such big XML files will be parsed in chunks, so
it is possbile, to keep track about the nr of overflows
by self, but come on.

It's surely a limbo dance by its own to introcude long
long in a source, so portable as expat, but that would
be it.

If you switch to long long if avaliable for this,
please consider also XML_GetCurrentLineNumber() and
XML_GetCurrentColumnNumber(). They return an int, which
is on most 32-byte systems 2 Gig. Though, I'm not
stumbled over this two limits in real life, as I in
fact did with XML_GetCurrentByteIndex(). 

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 15:31

Message:
Logged In: YES 
user_id=290026


You are right, Rolf, it should be 64 bits even on a 32bit
platform. I guess I should make a note in the docs that 
Expat supports > 2GB files, as long as each chunk passed
to the XML_Parse routines is smaller than 2GB.

There are also issues around compiling Expat on a 64bit
platform, but at least for VC++, someone has provided
a patch (bug # 1105135) which looks it should work
on other platforms as well (just a bunch of type casts).

One issue I have already seen is that VC++ 6.0 does not
know about long long.

Thanks for having a look at the cross-platform issue.

I am trying to get Expat 2.0 released despite Fred
not being active on Expat anymore.

Karl

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

Comment By: Rolf Ade (pointsman)
Date: 2005-11-27 15:22

Message:
Logged In: YES 
user_id=13222

Karl,

Most reasonable 32bit platforms have support for file sizes
> 2 GB these days even on 32. It was in fact a 32bit
platform, at which I stumbled over the problem. That for
your easy question.

Much harder is how to slove this in a portable way. I'm
afraid that may need platform depending #defines (with
fallback to long).

I'll go out digging what other portable software does in
this case and will come back with a more concrete proposal.

rolf




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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 14:22

Message:
Logged In: YES 
user_id=290026

Rolf,

should the type be 64 bit integer on all platforms,
or 32bit on 32bit platforms and 64bit on 64bit platforms?
I think we are talking about m_parseEndByteIndex,
POSITION.lineNumber and POSITION.columnNumber.

Options could be size_t, ptrdiff_t.
MS VC++ 6.0 does not know about long long, but it knows
about __int64. Is there an ANSI definition for 64 bit ints?

What do you suggest that works on all platforms?

Karl





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

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

From noreply at sourceforge.net  Sun Nov 27 21:44:19 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 Nov 2005 12:44:19 -0800
Subject: [Expat-bugs] [ expat-Bugs-1105135 ] Win64 portability warnings
Message-ID: <E1EgTNj-0002eU-OH@sc8-sf-web2.sourceforge.net>

Bugs item #1105135, was opened at 2005-01-19 04:45
Message generated for change (Comment added) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1105135&group_id=10127

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Platform Specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Henrik Goldman (hgoldman)
>Assigned to: Karl Waclawek (kwaclaw)
Summary: Win64 portability warnings

Initial Comment:
I am trying to get my software ready for Win64 
(AMD64 / IA64). Currently I'm using Visual Studio .NET 
2003 with /Wp64 switch enabled. However theres some 
missing typecasts in expat to make it compile clean.

Instead of waiting for someone to fix it I can probably do 
it myself but I'm only willing to if my changes will be 
considered for next release. I'm rather sure all the 
warnings will go away with apropriate typecasts. Please 
advise me how to continue.

I'm using the downloaded version of expat 1.95.8:

c:\myprog\shared\libs\expat-1.95.8\lib\xmltok_impl.c
(1717) : warning C4244:
 'return' : conversion from '__w64 int' to 'int', possible 
loss of data
c:\myprog\shared\libs\expat-1.95.8\lib\xmltok_impl.c
(1717) : warning C4244:
 'return' : conversion from '__w64 int' to 'int', possible 
loss of data
c:\myprog\shared\libs\expat-1.95.8\lib\xmltok_impl.c
(1717) : warning C4244:
 'return' : conversion from '__w64 int' to 'int', possible 
loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(1604) : 
warning C4244: 'initializi
ng' : conversion from '__w64 int' to 'int', possible loss of 
data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(1606) : 
warning C4244: 'initializi
ng' : conversion from '__w64 int' to 'int', possible loss of 
data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(1615) : 
warning C4244: 'initializi
ng' : conversion from '__w64 int' to 'int', possible loss of 
data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(1628) : 
warning C4244: 'initializi
ng' : conversion from '__w64 int' to 'int', possible loss of 
data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(1642) : 
warning C4244: 'initializi
ng' : conversion from '__w64 int' to 'int', possible loss of 
data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(1761) : 
warning C4244: 'return' :
conversion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(1770) : 
warning C4244: '=' : conve
rsion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(1771) : 
warning C4244: '=' : conve
rsion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(2318) : 
warning C4244: '=' : conve
rsion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(2323) : 
warning C4244: '=' : conve
rsion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(2511) : 
warning C4244: 'function'
: conversion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(2516) : 
warning C4244: 'function'
: conversion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(2541) : 
warning C4244: 'function'
: conversion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(2550) : 
warning C4244: 'function'
: conversion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(3067) : 
warning C4244: 'function'
: conversion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(3076) : 
warning C4244: 'function'
: conversion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(3938) : 
warning C4244: '=' : conve
rsion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(4623) : 
warning C4244: '=' : conve
rsion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(4669) : 
warning C4244: '=' : conve
rsion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(5130) : 
warning C4244: 'function'
: conversion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(5135) : 
warning C4244: 'function'
: conversion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(6017) : 
warning C4244: 'initializi
ng' : conversion from '__w64 int' to 'int', possible loss of 
data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(6031) : 
warning C4244: 'initializi
ng' : conversion from '__w64 int' to 'int', possible loss of 
data

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 15:44

Message:
Logged In: YES 
user_id=290026

It seems this patch should work on other platforms as well.
I'll have a look at this together with issue # 1284386.

Karl

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

Comment By: Henrik Goldman (hgoldman)
Date: 2005-03-27 06:52

Message:
Logged In: YES 
user_id=798004

I don't understand why anyone hasn't looked at the patches 
yet? Sooner or later you will get more of these Win64 x64 
requests because it's soon to be released as final and then 
people will want to write software for it.

The patches I submitted are quite trivial which you will see 
when looking through them.

Thanks.

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

Comment By: Henrik Goldman (hgoldman)
Date: 2005-02-07 10:11

Message:
Logged In: YES 
user_id=798004

So did anyone look at the patch?

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

Comment By: Henrik Goldman (hgoldman)
Date: 2005-01-30 10:41

Message:
Logged In: YES 
user_id=798004

Ok, so I patched my local 1.95.8 distribution and created a 
diff file. All the patches I made, are __int64 to int typecast 
warnings. All of them were fixed by adding parentheses and 
adding a (int) typecast.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2005-01-27 00:46

Message:
Logged In: YES 
user_id=3066

We'll certainly consider patches.  The best way to proceed 
would be to attach a patch to this bug report. 

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

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

From noreply at sourceforge.net  Sun Nov 27 21:45:37 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 Nov 2005 12:45:37 -0800
Subject: [Expat-bugs] [ expat-Bugs-1088215 ] Inconsistent namespace separator
Message-ID: <E1EgTOz-0002p4-9K@sc8-sf-web2.sourceforge.net>

Bugs item #1088215, was opened at 2004-12-20 00:16
Message generated for change (Settings changed) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1088215&group_id=10127

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Test Required
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Karl Waclawek (kwaclaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Inconsistent namespace separator

Initial Comment:
When the namespace separator is the null character, it will
be omitted between uri and local name.  However, when 
namespace triplets are turned on, the namespace separator 
between local name and prefix is inconsistently treated,
sometimes omitted, sometimes not. 

The attached patch enforces consistent behaviour such that
the separator between local name and prefix is never
omitted.
This is OK because it is an error to use a null
separator in the
case of namespace triplets, as per the documentation for
XML_ParserCreateNS().

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-12-20 00:17

Message:
Logged In: YES 
user_id=290026

The patch was applied in xmlparse.c rev. 1.139.
Testing required - assigned to Fred.

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

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

From noreply at sourceforge.net  Sun Nov 27 22:33:48 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 Nov 2005 13:33:48 -0800
Subject: [Expat-bugs] [ expat-Bugs-946506 ] PublicId for DOCTYPE not checked
	& normalized
Message-ID: <E1EgU9c-0007x5-JC@sc8-sf-web4.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Test Required
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Karl Waclawek (kwaclaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PublicId for DOCTYPE not checked & normalized

Initial Comment:
The public id passed to the StartDocTypeDeclHandler()
is not checked for legal characters and not normalized.

However, the same public id passed to the 
ExternalEntityRefHandler() is normalized.

This is because the former uses the docTypePubId
member and the latter uses a hash table lookup for a
declared entity.



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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-05-02 13:33

Message:
Logged In: YES 
user_id=290026

Fixed with attached patch in xmlparse.c rev. 1.133.

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

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

From noreply at sourceforge.net  Mon Nov 28 00:21:32 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 Nov 2005 15:21:32 -0800
Subject: [Expat-bugs] [ expat-Bugs-1284386 ] Byte count in large XML files
	fails
Message-ID: <E1EgVps-00012k-Nh@sc8-sf-web4.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rolf Ade (pointsman)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Byte count in large XML files fails

Initial Comment:

XML_GetCurrentByteIndex(XML_Parser parser) returns a
long, which is at least on the most 32 bit Systems 32
bit long. That means, for XML input larger than 2 GByte
file size, XML_GetCurrentByteIndex() returns does not
return the right number.

Sure, such big XML files will be parsed in chunks, so
it is possbile, to keep track about the nr of overflows
by self, but come on.

It's surely a limbo dance by its own to introcude long
long in a source, so portable as expat, but that would
be it.

If you switch to long long if avaliable for this,
please consider also XML_GetCurrentLineNumber() and
XML_GetCurrentColumnNumber(). They return an int, which
is on most 32-byte systems 2 Gig. Though, I'm not
stumbled over this two limits in real life, as I in
fact did with XML_GetCurrentByteIndex(). 

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 18:21

Message:
Logged In: YES 
user_id=290026

Just some notes, so that I don't forget

- should it be configurable?
  some may not want the overhead of a 64bit integer, 
  especially for line number and column number.
- is long long acceptable everywhere else
  (other than VC++)?
- the byte index could be negative, but not
  line/column number and byte count, right?
  

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 15:31

Message:
Logged In: YES 
user_id=290026


You are right, Rolf, it should be 64 bits even on a 32bit
platform. I guess I should make a note in the docs that 
Expat supports > 2GB files, as long as each chunk passed
to the XML_Parse routines is smaller than 2GB.

There are also issues around compiling Expat on a 64bit
platform, but at least for VC++, someone has provided
a patch (bug # 1105135) which looks it should work
on other platforms as well (just a bunch of type casts).

One issue I have already seen is that VC++ 6.0 does not
know about long long.

Thanks for having a look at the cross-platform issue.

I am trying to get Expat 2.0 released despite Fred
not being active on Expat anymore.

Karl

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

Comment By: Rolf Ade (pointsman)
Date: 2005-11-27 15:22

Message:
Logged In: YES 
user_id=13222

Karl,

Most reasonable 32bit platforms have support for file sizes
> 2 GB these days even on 32. It was in fact a 32bit
platform, at which I stumbled over the problem. That for
your easy question.

Much harder is how to slove this in a portable way. I'm
afraid that may need platform depending #defines (with
fallback to long).

I'll go out digging what other portable software does in
this case and will come back with a more concrete proposal.

rolf




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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 14:22

Message:
Logged In: YES 
user_id=290026

Rolf,

should the type be 64 bit integer on all platforms,
or 32bit on 32bit platforms and 64bit on 64bit platforms?
I think we are talking about m_parseEndByteIndex,
POSITION.lineNumber and POSITION.columnNumber.

Options could be size_t, ptrdiff_t.
MS VC++ 6.0 does not know about long long, but it knows
about __int64. Is there an ANSI definition for 64 bit ints?

What do you suggest that works on all platforms?

Karl





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

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

From noreply at sourceforge.net  Mon Nov 28 01:33:38 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 Nov 2005 16:33:38 -0800
Subject: [Expat-bugs] [ expat-Bugs-1284386 ] Byte count in large XML files
	fails
Message-ID: <E1EgWxe-0004QQ-Hy@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rolf Ade (pointsman)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Byte count in large XML files fails

Initial Comment:

XML_GetCurrentByteIndex(XML_Parser parser) returns a
long, which is at least on the most 32 bit Systems 32
bit long. That means, for XML input larger than 2 GByte
file size, XML_GetCurrentByteIndex() returns does not
return the right number.

Sure, such big XML files will be parsed in chunks, so
it is possbile, to keep track about the nr of overflows
by self, but come on.

It's surely a limbo dance by its own to introcude long
long in a source, so portable as expat, but that would
be it.

If you switch to long long if avaliable for this,
please consider also XML_GetCurrentLineNumber() and
XML_GetCurrentColumnNumber(). They return an int, which
is on most 32-byte systems 2 Gig. Though, I'm not
stumbled over this two limits in real life, as I in
fact did with XML_GetCurrentByteIndex(). 

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

>Comment By: Rolf Ade (pointsman)
Date: 2005-11-28 00:33

Message:
Logged In: YES 
user_id=13222

Configurable: No
There is nearly no overhead: just a few variables (at max) 8
bytes long instead of 4 bytes. Also speedwise: not mesuarable.

long long acceptable everywhere: Probably no
Some very old or limited embedded system may not have a long
long (or equivalent). Therefor we probably need defines.

Byte index could be negative: don't think so.
How could that happen? Byte index starts at 0 and grows. Or
do I miss something.?


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 23:21

Message:
Logged In: YES 
user_id=290026

Just some notes, so that I don't forget

- should it be configurable?
  some may not want the overhead of a 64bit integer, 
  especially for line number and column number.
- is long long acceptable everywhere else
  (other than VC++)?
- the byte index could be negative, but not
  line/column number and byte count, right?
  

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 20:31

Message:
Logged In: YES 
user_id=290026


You are right, Rolf, it should be 64 bits even on a 32bit
platform. I guess I should make a note in the docs that 
Expat supports > 2GB files, as long as each chunk passed
to the XML_Parse routines is smaller than 2GB.

There are also issues around compiling Expat on a 64bit
platform, but at least for VC++, someone has provided
a patch (bug # 1105135) which looks it should work
on other platforms as well (just a bunch of type casts).

One issue I have already seen is that VC++ 6.0 does not
know about long long.

Thanks for having a look at the cross-platform issue.

I am trying to get Expat 2.0 released despite Fred
not being active on Expat anymore.

Karl

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

Comment By: Rolf Ade (pointsman)
Date: 2005-11-27 20:22

Message:
Logged In: YES 
user_id=13222

Karl,

Most reasonable 32bit platforms have support for file sizes
> 2 GB these days even on 32. It was in fact a 32bit
platform, at which I stumbled over the problem. That for
your easy question.

Much harder is how to slove this in a portable way. I'm
afraid that may need platform depending #defines (with
fallback to long).

I'll go out digging what other portable software does in
this case and will come back with a more concrete proposal.

rolf




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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 19:22

Message:
Logged In: YES 
user_id=290026

Rolf,

should the type be 64 bit integer on all platforms,
or 32bit on 32bit platforms and 64bit on 64bit platforms?
I think we are talking about m_parseEndByteIndex,
POSITION.lineNumber and POSITION.columnNumber.

Options could be size_t, ptrdiff_t.
MS VC++ 6.0 does not know about long long, but it knows
about __int64. Is there an ANSI definition for 64 bit ints?

What do you suggest that works on all platforms?

Karl





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

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

From noreply at sourceforge.net  Mon Nov 28 02:00:42 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 Nov 2005 17:00:42 -0800
Subject: [Expat-bugs] [ expat-Bugs-1284386 ] Byte count in large XML files
	fails
Message-ID: <E1EgXNq-000286-KI@sc8-sf-web4.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rolf Ade (pointsman)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Byte count in large XML files fails

Initial Comment:

XML_GetCurrentByteIndex(XML_Parser parser) returns a
long, which is at least on the most 32 bit Systems 32
bit long. That means, for XML input larger than 2 GByte
file size, XML_GetCurrentByteIndex() returns does not
return the right number.

Sure, such big XML files will be parsed in chunks, so
it is possbile, to keep track about the nr of overflows
by self, but come on.

It's surely a limbo dance by its own to introcude long
long in a source, so portable as expat, but that would
be it.

If you switch to long long if avaliable for this,
please consider also XML_GetCurrentLineNumber() and
XML_GetCurrentColumnNumber(). They return an int, which
is on most 32-byte systems 2 Gig. Though, I'm not
stumbled over this two limits in real life, as I in
fact did with XML_GetCurrentByteIndex(). 

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 20:00

Message:
Logged In: YES 
user_id=290026

On a 32bit CPU, 64bit integer operations are considerably 
slower than 32 bit operations. On the other hand 
XMLUpdatePosition isn't called that often - mostly when 
you actually request the line/column number.
So, I agree - no configuration necessary.

For the other point:
If you look at the XML_GetCurrentByteIndex() code, it can 
return -1, and it is calculated using a subtraction. So in 
practice and theory, it must be a signed integer.

XML_GetCurrentByteCount is derived from a subtraction as 
well, but we know it will be positive because eventEndPtr 
should always be larger than eventPtr. So we could risk 
using an unsigned integer.

Just playing around, I added this to expat_external.h:
#ifdef XML_USE_MSC_EXTENSIONS
typedef __int64 XML_Int64;
typedef unsigned __int64 XML_UInt64;
#else
typedef long long XML_Int64;
typedef unsigned long long XML_UInt64;
#endif

What do you think?

Karl

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

Comment By: Rolf Ade (pointsman)
Date: 2005-11-27 19:33

Message:
Logged In: YES 
user_id=13222

Configurable: No
There is nearly no overhead: just a few variables (at max) 8
bytes long instead of 4 bytes. Also speedwise: not mesuarable.

long long acceptable everywhere: Probably no
Some very old or limited embedded system may not have a long
long (or equivalent). Therefor we probably need defines.

Byte index could be negative: don't think so.
How could that happen? Byte index starts at 0 and grows. Or
do I miss something.?


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 18:21

Message:
Logged In: YES 
user_id=290026

Just some notes, so that I don't forget

- should it be configurable?
  some may not want the overhead of a 64bit integer, 
  especially for line number and column number.
- is long long acceptable everywhere else
  (other than VC++)?
- the byte index could be negative, but not
  line/column number and byte count, right?
  

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 15:31

Message:
Logged In: YES 
user_id=290026


You are right, Rolf, it should be 64 bits even on a 32bit
platform. I guess I should make a note in the docs that 
Expat supports > 2GB files, as long as each chunk passed
to the XML_Parse routines is smaller than 2GB.

There are also issues around compiling Expat on a 64bit
platform, but at least for VC++, someone has provided
a patch (bug # 1105135) which looks it should work
on other platforms as well (just a bunch of type casts).

One issue I have already seen is that VC++ 6.0 does not
know about long long.

Thanks for having a look at the cross-platform issue.

I am trying to get Expat 2.0 released despite Fred
not being active on Expat anymore.

Karl

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

Comment By: Rolf Ade (pointsman)
Date: 2005-11-27 15:22

Message:
Logged In: YES 
user_id=13222

Karl,

Most reasonable 32bit platforms have support for file sizes
> 2 GB these days even on 32. It was in fact a 32bit
platform, at which I stumbled over the problem. That for
your easy question.

Much harder is how to slove this in a portable way. I'm
afraid that may need platform depending #defines (with
fallback to long).

I'll go out digging what other portable software does in
this case and will come back with a more concrete proposal.

rolf




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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 14:22

Message:
Logged In: YES 
user_id=290026

Rolf,

should the type be 64 bit integer on all platforms,
or 32bit on 32bit platforms and 64bit on 64bit platforms?
I think we are talking about m_parseEndByteIndex,
POSITION.lineNumber and POSITION.columnNumber.

Options could be size_t, ptrdiff_t.
MS VC++ 6.0 does not know about long long, but it knows
about __int64. Is there an ANSI definition for 64 bit ints?

What do you suggest that works on all platforms?

Karl





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

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

From noreply at sourceforge.net  Mon Nov 28 03:01:08 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 Nov 2005 18:01:08 -0800
Subject: [Expat-bugs] [ expat-Bugs-1284386 ] Byte count in large XML files
	fails
Message-ID: <E1EgYKK-0005OS-UZ@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rolf Ade (pointsman)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Byte count in large XML files fails

Initial Comment:

XML_GetCurrentByteIndex(XML_Parser parser) returns a
long, which is at least on the most 32 bit Systems 32
bit long. That means, for XML input larger than 2 GByte
file size, XML_GetCurrentByteIndex() returns does not
return the right number.

Sure, such big XML files will be parsed in chunks, so
it is possbile, to keep track about the nr of overflows
by self, but come on.

It's surely a limbo dance by its own to introcude long
long in a source, so portable as expat, but that would
be it.

If you switch to long long if avaliable for this,
please consider also XML_GetCurrentLineNumber() and
XML_GetCurrentColumnNumber(). They return an int, which
is on most 32-byte systems 2 Gig. Though, I'm not
stumbled over this two limits in real life, as I in
fact did with XML_GetCurrentByteIndex(). 

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

>Comment By: Rolf Ade (pointsman)
Date: 2005-11-28 02:01

Message:
Logged In: YES 
user_id=13222

XML_GetCurrentByteIndex() could return -1:
Of course! You're right. And it makes sense. A freshly
created or reseted parser  without the first XML_Parse()
call returns -1 on XML_GetCurrentByteIndex(), to signal this
fact: it is not right at the start of the document, but
there isn't any parsing started yet. Nice detail. I should
have looked at the implementation, before replying. Note:
That detail isn't mentioned in the documentation.

I'm fine with a signed long long. 2^63 should be big enough,
for the next few weeks ;-).

Re the defines: Basically yes. It's just, that I'm pretty
sure, we need one round more: some configure check for long
long and depending on that result defining XML_?Int64 as
long long or just long.

I'll look something up (but being on deadline catching, may
need a bit time). 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-28 01:00

Message:
Logged In: YES 
user_id=290026

On a 32bit CPU, 64bit integer operations are considerably 
slower than 32 bit operations. On the other hand 
XMLUpdatePosition isn't called that often - mostly when 
you actually request the line/column number.
So, I agree - no configuration necessary.

For the other point:
If you look at the XML_GetCurrentByteIndex() code, it can 
return -1, and it is calculated using a subtraction. So in 
practice and theory, it must be a signed integer.

XML_GetCurrentByteCount is derived from a subtraction as 
well, but we know it will be positive because eventEndPtr 
should always be larger than eventPtr. So we could risk 
using an unsigned integer.

Just playing around, I added this to expat_external.h:
#ifdef XML_USE_MSC_EXTENSIONS
typedef __int64 XML_Int64;
typedef unsigned __int64 XML_UInt64;
#else
typedef long long XML_Int64;
typedef unsigned long long XML_UInt64;
#endif

What do you think?

Karl

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

Comment By: Rolf Ade (pointsman)
Date: 2005-11-28 00:33

Message:
Logged In: YES 
user_id=13222

Configurable: No
There is nearly no overhead: just a few variables (at max) 8
bytes long instead of 4 bytes. Also speedwise: not mesuarable.

long long acceptable everywhere: Probably no
Some very old or limited embedded system may not have a long
long (or equivalent). Therefor we probably need defines.

Byte index could be negative: don't think so.
How could that happen? Byte index starts at 0 and grows. Or
do I miss something.?


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 23:21

Message:
Logged In: YES 
user_id=290026

Just some notes, so that I don't forget

- should it be configurable?
  some may not want the overhead of a 64bit integer, 
  especially for line number and column number.
- is long long acceptable everywhere else
  (other than VC++)?
- the byte index could be negative, but not
  line/column number and byte count, right?
  

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 20:31

Message:
Logged In: YES 
user_id=290026


You are right, Rolf, it should be 64 bits even on a 32bit
platform. I guess I should make a note in the docs that 
Expat supports > 2GB files, as long as each chunk passed
to the XML_Parse routines is smaller than 2GB.

There are also issues around compiling Expat on a 64bit
platform, but at least for VC++, someone has provided
a patch (bug # 1105135) which looks it should work
on other platforms as well (just a bunch of type casts).

One issue I have already seen is that VC++ 6.0 does not
know about long long.

Thanks for having a look at the cross-platform issue.

I am trying to get Expat 2.0 released despite Fred
not being active on Expat anymore.

Karl

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

Comment By: Rolf Ade (pointsman)
Date: 2005-11-27 20:22

Message:
Logged In: YES 
user_id=13222

Karl,

Most reasonable 32bit platforms have support for file sizes
> 2 GB these days even on 32. It was in fact a 32bit
platform, at which I stumbled over the problem. That for
your easy question.

Much harder is how to slove this in a portable way. I'm
afraid that may need platform depending #defines (with
fallback to long).

I'll go out digging what other portable software does in
this case and will come back with a more concrete proposal.

rolf




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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 19:22

Message:
Logged In: YES 
user_id=290026

Rolf,

should the type be 64 bit integer on all platforms,
or 32bit on 32bit platforms and 64bit on 64bit platforms?
I think we are talking about m_parseEndByteIndex,
POSITION.lineNumber and POSITION.columnNumber.

Options could be size_t, ptrdiff_t.
MS VC++ 6.0 does not know about long long, but it knows
about __int64. Is there an ANSI definition for 64 bit ints?

What do you suggest that works on all platforms?

Karl





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

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

From noreply at sourceforge.net  Mon Nov 28 18:49:10 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 Nov 2005 09:49:10 -0800
Subject: [Expat-bugs] [ expat-Bugs-1211302 ] building 2005-01-28 with
	mingw/msys
Message-ID: <E1Egn7m-00060z-TD@sc8-sf-web1.sourceforge.net>

Bugs item #1211302, was opened at 2005-05-30 14:31
Message generated for change (Comment added) made by siebenschlaefer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1211302&group_id=10127

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build control
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Gerrit P. Haase (siebenschlaefer)
Summary: building 2005-01-28 with mingw/msys

Initial Comment:
The libtool fails for some reason.

I have no idea how to debug/improve this so I will try
to use a prebuilt version.


/usr/src/expat-2005-01-28
$ make
/bin/sh ./libtool --silent --mode=compile gcc -I./lib
-I. -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H
 -I/aspell/include -I/gw32/include/ -I/mingwlib/include
-o lib/xmlparse.lo -c lib/xmlparse.c
/bin/sh ./libtool --silent --mode=compile gcc -I./lib
-I. -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H
 -I/aspell/include -I/gw32/include/ -I/mingwlib/include
-o lib/xmltok.lo -c lib/xmltok.c
/bin/sh ./libtool --silent --mode=compile gcc -I./lib
-I. -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H
 -I/aspell/include -I/gw32/include/ -I/mingwlib/include
-o lib/xmlrole.lo -c lib/xmlrole.c
/bin/sh ./libtool --silent --mode=link gcc -I./lib -I.
-g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes
-fexceptions -DHAVE_EXPAT_CONFIG_H  -I/aspell/include
-I/gw32/include/ -I/mingwlib/include -no-undefined
-version-info 5:0:5 -rpath /usr/local/lib -L/aspell/lib
-L/gw32/lib/ -L/mingw/lib -o libexpat.la
lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo
Creating library file: .libs/libexpat.dll.a
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H
 -I/aspell/include -I/gw32/include/ -I/mingwlib/include
-o xmlwf/xmlwf.o -c xmlwf/xmlwf.c
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H
 -I/aspell/include -I/gw32/include/ -I/mingwlib/include
-o xmlwf/xmlfile.o -c xmlwf/xmlfile.c
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H
 -I/aspell/include -I/gw32/include/ -I/mingwlib/include
-o xmlwf/codepage.o -c xmlwf/codepage.c
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H
 -I/aspell/include -I/gw32/include/ -I/mingwlib/include
-o xmlwf/readfilemap.o -c xmlwf/readfilemap.c
/bin/sh ./libtool --silent --mode=link gcc -I./lib -I.
-g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes
-fexceptions -DHAVE_EXPAT_CONFIG_H  -I/aspell/include
-I/gw32/include/ -I/mingwlib/include -L/aspell/lib
-L/gw32/lib/ -L/mingw/lib -o xmlwf/xmlwf xmlwf/xmlwf.o
xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/readfilemap.o
libexpat.la
./libtool: .libs/lt-xmlwf/xmlwf.c: No such file or
directory
./libtool: .libs/lt-xmlwf/xmlwf.c: No such file or
directory
./libtool: .libs/lt-xmlwf/xmlwf.c: No such file or
directory
./libtool: .libs/lt-xmlwf/xmlwf.c: No such file or
directory
./libtool: .libs/lt-xmlwf/xmlwf.c: No such file or
directory
./libtool: .libs/lt-xmlwf/xmlwf.c: No such file or
directory
gcc.exe: .libs/lt-xmlwf/xmlwf.c: No such file or directory
gcc.exe: no input files


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

>Comment By: Gerrit P. Haase (siebenschlaefer)
Date: 2005-11-28 18:49

Message:
Logged In: YES 
user_id=76037

This only happens when using an old libtool release like the
one included with the released tarball.  I always replace
ltmain.sh and libtool.m4 with the latest Cygwin version when
doing a binary release for Cygwin.  If Karl is going to make
the next release on his Cygwin installation it should be
fixed this way.

So basically it is a libtool bug.

If you want to build the 1.95.8 release, fetch the source
tarball form one of the Cygwin mirrors and use that instead
of the official source release.


Gerrit

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-06-15 14:40

Message:
Logged In: YES 
user_id=290026

Assigned to our Cygwin expert.

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

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

From noreply at sourceforge.net  Mon Nov 28 18:58:51 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 Nov 2005 09:58:51 -0800
Subject: [Expat-bugs] [ expat-Bugs-1063934 ] building expat-1.95.8 for win32
	with mingw
Message-ID: <E1EgnH9-0006Jt-62@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build control
Group: Third-party Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: building expat-1.95.8 for win32 with mingw 

Initial Comment:
Hi!

I'm compiling expat-1.95.8 for win32 with mingw in an
cygwin-enviroment. During buildprocess i get following
error:

/bin/bash ./libtool --silent --mode=link g++-mingw -g
-O2 -Wall -Wmissing-prototypes -Wstrict-prototypes
-fexceptions -DHAVE_EXPAT_CONFIG_H   -I./lib -I.
-no-undefined -version-info 5:0:5 -rpath
/wamas/test/erudig/WX/cygwin_win32/lib
-Wl,--export-all,--kill-at -o libxmiexpat.la
lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo
/usr/lib/gcc-lib/i686-pc-mingw32/3.3.3/../../../../i686-pc-mingw32/bin/ld:
warning: cannot find entry symbol
_DllMainCRTStartup at 12; defaulting to 00401000
/usr/lib/gcc-lib/i686-pc-mingw32/3.3.3/../../../../i686-pc-mingw32/lib/libmingw32.a(main.o)(.text+0x106):main.c:
undefined reference to `_WinMain at 16'
collect2: ld returned 1 exit status
make: *** [libxmiexpat.la] Error 1

I suppose the libtool-script which is generated during
configure is libtool-1.4.x. In this scipt they excluded
some dll-entrypoints for cygwin and mingw. I replaced
this script with the script of libtool-1.5.10 and all
worked fine.


So can you please replace the configure-scipt with an
scipt which is generated with libtool-1.5 or higher.

sincerely
Elmar Rudigier

ps: g++-mingw is is only a scipt which calls g++ whith
the flag -mno-cygwin to exclude cygwin.dll during linking.

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

>Comment By: Gerrit P. Haase (siebenschlaefer)
Date: 2005-11-28 18:58

Message:
Logged In: YES 
user_id=76037

See: 
http://sourceforge.net/tracker/index.php?func=detail&aid=1211302&group_id=10127&atid=110127

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

Comment By: heromyth (heromyth)
Date: 2005-03-28 06:01

Message:
Logged In: YES 
user_id=1190746

Use the newer script to do Make, just get a static lib, there is 
no shared lib.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2005-01-27 05:53

Message:
Logged In: YES 
user_id=3066

Using libtool 1.5.10 seems to work on my system (FC1), so 
I'll plan on using that for the next release. 
 
Assigning to me, since the version of libtool that gets 
used seems to be a matter of what's installed on the 
machine used to build the distribution. 
 

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-11-26 11:29

Message:
Logged In: NO 

Please check 
http://sourceforge.net/tracker/index.php?func=detail&aid=1073661&group_id=10127&atid=110127
I think it is solved

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

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

From noreply at sourceforge.net  Mon Nov 28 19:43:09 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 Nov 2005 10:43:09 -0800
Subject: [Expat-bugs] [ expat-Bugs-1073661 ] Expat-1.95.8 win32bin mingw32
	libraries
Message-ID: <E1Egny1-0003Nn-D4@sc8-sf-web4.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build control
Group: Platform Specific
>Status: Closed
>Resolution: Fixed
Priority: 4
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Expat-1.95.8 win32bin mingw32 libraries

Initial Comment:
There is a very little problem with the binary distribution of Expat-1.95.8.
I've been building from scratch perl 5.8.5 on win32, and encountered the same problem across several modules.
Most modules depend on external libraries. Most library distributions provide binary versions, some provide binaries.
Expat provides both dll and libraries. The problem is that libraries are for vc++ or bc, not for mingw.
The following procedure generates mingw dinamic libraries:
pexports libexpat.dll > expat.def
pexports libexpatw.dll > expatw.def
dlltool -d expat.def -l libexpat.a
dlltool -d expatw.def -l libexpatw.a
The *.a files are mingw libraries.
May be you can include them in the binary distribution.
You NEED to put the *.dll in your %PATH%.
Now you can just point XML-Parser instalation to your expat binary distribution:
whatever\XML-Parser-2.34>perl Makefile.pl EXPATLIBPATH=whatever2\Expat-1.95.8\Lib
s EXPATINCPATH=whatever2\Expat-1.95.8\Source\lib
dmake
dmake test
dmake install
Everything should run smoothly.
Greets
Bruno Diaz Briere
bruno.diaz-[@can at be_reached@at_host-[_gmx.net

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-28 13:43

Message:
Logged In: YES 
user_id=290026

Added instructions to README.txt in the Win32 directory.
Closing this issue.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-01-28 22:48

Message:
Logged In: YES 
user_id=290026

As far as I can tell, the .a files are import libraries which
help the linker link against the actual Win32 Dll.

I don't think we should include any mingw specific binaries,
but I'll see if I can add the instructions to the Win32 docs.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2005-01-28 21:35

Message:
Logged In: YES 
user_id=3066

Karl:  Unless you want to do this, I'm inclined to reject
this.  If this is easy for a MinGW user to do, it's
something that's reasonable for them to do themselves. 
That's simply part of using a minority compiler on a
majority-centric platform.

Assigning to you for a decision.


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2004-11-26 08:56

Message:
Logged In: YES 
user_id=290026

Why don't you provide a ready-made patch?

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

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

From noreply at sourceforge.net  Mon Nov 28 18:30:09 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 Nov 2005 09:30:09 -0800
Subject: [Expat-bugs] [ expat-Bugs-1368413 ] Prep AmigaOS changes 2.0 release
Message-ID: <E1EgmpN-0005R1-0z@sc8-sf-web1.sourceforge.net>

Bugs item #1368413, was opened at 2005-11-28 10:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1368413&group_id=10127

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Platform Specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Solie (ssolie)
Assigned to: Steven Solie (ssolie)
Summary: Prep AmigaOS changes 2.0 release

Initial Comment:
Prepare the AmigaOS specific expat changes for the
pending 2.0 release.

Some minor Makefile changes are needed and
documentation updated.

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

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

From noreply at sourceforge.net  Mon Nov 28 18:30:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 Nov 2005 09:30:36 -0800
Subject: [Expat-bugs] [ expat-Bugs-1368413 ] Prep AmigaOS changes for 2.0
	release
Message-ID: <E1Egmpo-0005S9-MR@sc8-sf-web1.sourceforge.net>

Bugs item #1368413, was opened at 2005-11-28 10:30
Message generated for change (Settings changed) made by ssolie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1368413&group_id=10127

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Platform Specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Solie (ssolie)
Assigned to: Steven Solie (ssolie)
>Summary: Prep AmigaOS changes for 2.0 release

Initial Comment:
Prepare the AmigaOS specific expat changes for the
pending 2.0 release.

Some minor Makefile changes are needed and
documentation updated.

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

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

From noreply at sourceforge.net  Mon Nov 28 21:12:54 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 Nov 2005 12:12:54 -0800
Subject: [Expat-bugs] [ expat-Bugs-1105135 ] Win64 portability warnings
Message-ID: <E1EgpMs-0004tE-T0@sc8-sf-web3.sourceforge.net>

Bugs item #1105135, was opened at 2005-01-19 04:45
Message generated for change (Comment added) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1105135&group_id=10127

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
>Group: Test Required
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Henrik Goldman (hgoldman)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Win64 portability warnings

Initial Comment:
I am trying to get my software ready for Win64 
(AMD64 / IA64). Currently I'm using Visual Studio .NET 
2003 with /Wp64 switch enabled. However theres some 
missing typecasts in expat to make it compile clean.

Instead of waiting for someone to fix it I can probably do 
it myself but I'm only willing to if my changes will be 
considered for next release. I'm rather sure all the 
warnings will go away with apropriate typecasts. Please 
advise me how to continue.

I'm using the downloaded version of expat 1.95.8:

c:\myprog\shared\libs\expat-1.95.8\lib\xmltok_impl.c
(1717) : warning C4244:
 'return' : conversion from '__w64 int' to 'int', possible 
loss of data
c:\myprog\shared\libs\expat-1.95.8\lib\xmltok_impl.c
(1717) : warning C4244:
 'return' : conversion from '__w64 int' to 'int', possible 
loss of data
c:\myprog\shared\libs\expat-1.95.8\lib\xmltok_impl.c
(1717) : warning C4244:
 'return' : conversion from '__w64 int' to 'int', possible 
loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(1604) : 
warning C4244: 'initializi
ng' : conversion from '__w64 int' to 'int', possible loss of 
data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(1606) : 
warning C4244: 'initializi
ng' : conversion from '__w64 int' to 'int', possible loss of 
data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(1615) : 
warning C4244: 'initializi
ng' : conversion from '__w64 int' to 'int', possible loss of 
data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(1628) : 
warning C4244: 'initializi
ng' : conversion from '__w64 int' to 'int', possible loss of 
data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(1642) : 
warning C4244: 'initializi
ng' : conversion from '__w64 int' to 'int', possible loss of 
data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(1761) : 
warning C4244: 'return' :
conversion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(1770) : 
warning C4244: '=' : conve
rsion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(1771) : 
warning C4244: '=' : conve
rsion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(2318) : 
warning C4244: '=' : conve
rsion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(2323) : 
warning C4244: '=' : conve
rsion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(2511) : 
warning C4244: 'function'
: conversion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(2516) : 
warning C4244: 'function'
: conversion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(2541) : 
warning C4244: 'function'
: conversion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(2550) : 
warning C4244: 'function'
: conversion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(3067) : 
warning C4244: 'function'
: conversion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(3076) : 
warning C4244: 'function'
: conversion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(3938) : 
warning C4244: '=' : conve
rsion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(4623) : 
warning C4244: '=' : conve
rsion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(4669) : 
warning C4244: '=' : conve
rsion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(5130) : 
warning C4244: 'function'
: conversion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(5135) : 
warning C4244: 'function'
: conversion from '__w64 int' to 'int', possible loss of data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(6017) : 
warning C4244: 'initializi
ng' : conversion from '__w64 int' to 'int', possible loss of 
data
../../shared\libs\expat-1.95.8\lib\xmlparse.c(6031) : 
warning C4244: 'initializi
ng' : conversion from '__w64 int' to 'int', possible loss of 
data

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-28 15:12

Message:
Logged In: YES 
user_id=290026

Applied the type casts in xmlparse.c rev. 1.150 and
xmltok_impl.c rev. 1.11.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 15:44

Message:
Logged In: YES 
user_id=290026

It seems this patch should work on other platforms as well.
I'll have a look at this together with issue # 1284386.

Karl

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

Comment By: Henrik Goldman (hgoldman)
Date: 2005-03-27 06:52

Message:
Logged In: YES 
user_id=798004

I don't understand why anyone hasn't looked at the patches 
yet? Sooner or later you will get more of these Win64 x64 
requests because it's soon to be released as final and then 
people will want to write software for it.

The patches I submitted are quite trivial which you will see 
when looking through them.

Thanks.

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

Comment By: Henrik Goldman (hgoldman)
Date: 2005-02-07 10:11

Message:
Logged In: YES 
user_id=798004

So did anyone look at the patch?

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

Comment By: Henrik Goldman (hgoldman)
Date: 2005-01-30 10:41

Message:
Logged In: YES 
user_id=798004

Ok, so I patched my local 1.95.8 distribution and created a 
diff file. All the patches I made, are __int64 to int typecast 
warnings. All of them were fixed by adding parentheses and 
adding a (int) typecast.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2005-01-27 00:46

Message:
Logged In: YES 
user_id=3066

We'll certainly consider patches.  The best way to proceed 
would be to attach a patch to this bug report. 

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

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

From noreply at sourceforge.net  Tue Nov 29 00:49:45 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 Nov 2005 15:49:45 -0800
Subject: [Expat-bugs] [ expat-Bugs-1368713 ] Install does not install
	expat_external.h
Message-ID: <E1Egskj-0002w8-3f@sc8-sf-web3.sourceforge.net>

Bugs item #1368713, was opened at 2005-11-28 15:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1368713&group_id=10127

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build control
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Van Tassell (russellvt)
Assigned to: Greg Stein (gstein)
Summary: Install does not install expat_external.h

Initial Comment:
The install process does not seem to properly install
./lib/expat_external.h (though it seems to try).  This
is Expat version 1.95.8 on Solaris 9.

Steps to reproduce:

% ./configure --prefix=/tmp/expat
% gmake
% gmake -n install
% gmake install

Output from "gmake -n" is:

/bin/bash ./conftools/mkinstalldirs /tmp/expat/lib
/tmp/expat/include
/bin/bash ./libtool --mode=install conftools/install-sh
-c libexpat.la /tmp/expat/lib/libexpat.la
conftools/install-sh -c -m 644 ./lib/expat.h
./lib/expat_external.h /tmp/expat/include
/bin/bash ./conftools/mkinstalldirs /tmp/expat/bin
/tmp/expat/man/man1
/bin/bash ./libtool --mode=install conftools/install-sh
-c xmlwf/xmlwf /tmp/expat/bin/xmlwf
conftools/install-sh -c -m 644 ./doc/xmlwf.1
/tmp/expat/man/man1


Looks like install only takes a source file and a list
of destination directories rather than a list of files
and a single destination.

Apologies if this is redundant... only other references
to this issue I could find are at:

http://mail.libexpat.org/pipermail/expat-discuss/2004-August/001521.html

Changelog would appear to state that it had been added
to the install process (Fri Jul 16 2004).

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

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

From noreply at sourceforge.net  Tue Nov 29 02:34:08 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 Nov 2005 17:34:08 -0800
Subject: [Expat-bugs] [ expat-Bugs-1368713 ] Install does not install
	expat_external.h
Message-ID: <E1EguNk-0000at-Q3@sc8-sf-web1.sourceforge.net>

Bugs item #1368713, was opened at 2005-11-28 18:49
Message generated for change (Comment added) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1368713&group_id=10127

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build control
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Russell Van Tassell (russellvt)
Assigned to: Greg Stein (gstein)
Summary: Install does not install expat_external.h

Initial Comment:
The install process does not seem to properly install
./lib/expat_external.h (though it seems to try).  This
is Expat version 1.95.8 on Solaris 9.

Steps to reproduce:

% ./configure --prefix=/tmp/expat
% gmake
% gmake -n install
% gmake install

Output from "gmake -n" is:

/bin/bash ./conftools/mkinstalldirs /tmp/expat/lib
/tmp/expat/include
/bin/bash ./libtool --mode=install conftools/install-sh
-c libexpat.la /tmp/expat/lib/libexpat.la
conftools/install-sh -c -m 644 ./lib/expat.h
./lib/expat_external.h /tmp/expat/include
/bin/bash ./conftools/mkinstalldirs /tmp/expat/bin
/tmp/expat/man/man1
/bin/bash ./libtool --mode=install conftools/install-sh
-c xmlwf/xmlwf /tmp/expat/bin/xmlwf
conftools/install-sh -c -m 644 ./doc/xmlwf.1
/tmp/expat/man/man1


Looks like install only takes a source file and a list
of destination directories rather than a list of files
and a single destination.

Apologies if this is redundant... only other references
to this issue I could find are at:

http://mail.libexpat.org/pipermail/expat-discuss/2004-August/001521.html

Changelog would appear to state that it had been added
to the install process (Fri Jul 16 2004).

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-28 20:34

Message:
Logged In: YES 
user_id=290026

Closed - duplicate of issue #1177957.


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

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

From noreply at sourceforge.net  Wed Nov 30 15:31:40 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 Nov 2005 06:31:40 -0800
Subject: [Expat-bugs] [ expat-Bugs-1284386 ] Byte count in large XML files
	fails
Message-ID: <E1EhSzk-0003Az-T7@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rolf Ade (pointsman)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Byte count in large XML files fails

Initial Comment:

XML_GetCurrentByteIndex(XML_Parser parser) returns a
long, which is at least on the most 32 bit Systems 32
bit long. That means, for XML input larger than 2 GByte
file size, XML_GetCurrentByteIndex() returns does not
return the right number.

Sure, such big XML files will be parsed in chunks, so
it is possbile, to keep track about the nr of overflows
by self, but come on.

It's surely a limbo dance by its own to introcude long
long in a source, so portable as expat, but that would
be it.

If you switch to long long if avaliable for this,
please consider also XML_GetCurrentLineNumber() and
XML_GetCurrentColumnNumber(). They return an int, which
is on most 32-byte systems 2 Gig. Though, I'm not
stumbled over this two limits in real life, as I in
fact did with XML_GetCurrentByteIndex(). 

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-30 09:31

Message:
Logged In: YES 
user_id=290026

Rolf,

I opened a discussion about this on the discussion list.
The main issue - IMO - is backwards compatibility.
I don't know how many apps on Linux, for instance, rely
on the Expat API staying binary compatible.

Karl

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

Comment By: Rolf Ade (pointsman)
Date: 2005-11-27 21:01

Message:
Logged In: YES 
user_id=13222

XML_GetCurrentByteIndex() could return -1:
Of course! You're right. And it makes sense. A freshly
created or reseted parser  without the first XML_Parse()
call returns -1 on XML_GetCurrentByteIndex(), to signal this
fact: it is not right at the start of the document, but
there isn't any parsing started yet. Nice detail. I should
have looked at the implementation, before replying. Note:
That detail isn't mentioned in the documentation.

I'm fine with a signed long long. 2^63 should be big enough,
for the next few weeks ;-).

Re the defines: Basically yes. It's just, that I'm pretty
sure, we need one round more: some configure check for long
long and depending on that result defining XML_?Int64 as
long long or just long.

I'll look something up (but being on deadline catching, may
need a bit time). 

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 20:00

Message:
Logged In: YES 
user_id=290026

On a 32bit CPU, 64bit integer operations are considerably 
slower than 32 bit operations. On the other hand 
XMLUpdatePosition isn't called that often - mostly when 
you actually request the line/column number.
So, I agree - no configuration necessary.

For the other point:
If you look at the XML_GetCurrentByteIndex() code, it can 
return -1, and it is calculated using a subtraction. So in 
practice and theory, it must be a signed integer.

XML_GetCurrentByteCount is derived from a subtraction as 
well, but we know it will be positive because eventEndPtr 
should always be larger than eventPtr. So we could risk 
using an unsigned integer.

Just playing around, I added this to expat_external.h:
#ifdef XML_USE_MSC_EXTENSIONS
typedef __int64 XML_Int64;
typedef unsigned __int64 XML_UInt64;
#else
typedef long long XML_Int64;
typedef unsigned long long XML_UInt64;
#endif

What do you think?

Karl

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

Comment By: Rolf Ade (pointsman)
Date: 2005-11-27 19:33

Message:
Logged In: YES 
user_id=13222

Configurable: No
There is nearly no overhead: just a few variables (at max) 8
bytes long instead of 4 bytes. Also speedwise: not mesuarable.

long long acceptable everywhere: Probably no
Some very old or limited embedded system may not have a long
long (or equivalent). Therefor we probably need defines.

Byte index could be negative: don't think so.
How could that happen? Byte index starts at 0 and grows. Or
do I miss something.?


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 18:21

Message:
Logged In: YES 
user_id=290026

Just some notes, so that I don't forget

- should it be configurable?
  some may not want the overhead of a 64bit integer, 
  especially for line number and column number.
- is long long acceptable everywhere else
  (other than VC++)?
- the byte index could be negative, but not
  line/column number and byte count, right?
  

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 15:31

Message:
Logged In: YES 
user_id=290026


You are right, Rolf, it should be 64 bits even on a 32bit
platform. I guess I should make a note in the docs that 
Expat supports > 2GB files, as long as each chunk passed
to the XML_Parse routines is smaller than 2GB.

There are also issues around compiling Expat on a 64bit
platform, but at least for VC++, someone has provided
a patch (bug # 1105135) which looks it should work
on other platforms as well (just a bunch of type casts).

One issue I have already seen is that VC++ 6.0 does not
know about long long.

Thanks for having a look at the cross-platform issue.

I am trying to get Expat 2.0 released despite Fred
not being active on Expat anymore.

Karl

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

Comment By: Rolf Ade (pointsman)
Date: 2005-11-27 15:22

Message:
Logged In: YES 
user_id=13222

Karl,

Most reasonable 32bit platforms have support for file sizes
> 2 GB these days even on 32. It was in fact a 32bit
platform, at which I stumbled over the problem. That for
your easy question.

Much harder is how to slove this in a portable way. I'm
afraid that may need platform depending #defines (with
fallback to long).

I'll go out digging what other portable software does in
this case and will come back with a more concrete proposal.

rolf




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

Comment By: Karl Waclawek (kwaclaw)
Date: 2005-11-27 14:22

Message:
Logged In: YES 
user_id=290026

Rolf,

should the type be 64 bit integer on all platforms,
or 32bit on 32bit platforms and 64bit on 64bit platforms?
I think we are talking about m_parseEndByteIndex,
POSITION.lineNumber and POSITION.columnNumber.

Options could be size_t, ptrdiff_t.
MS VC++ 6.0 does not know about long long, but it knows
about __int64. Is there an ANSI definition for 64 bit ints?

What do you suggest that works on all platforms?

Karl





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

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