[Expat-bugs] [ expat-Patches-1437840 ] Compile fix rollup patch against 2.0.0
SourceForge.net
noreply at sourceforge.net
Tue Dec 12 20:17:22 CET 2006
Patches item #1437840, was opened at 2006-02-23 21:58
Message generated for change (Comment added) made by kwaclaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1437840&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
Private: No
Submitted By: Mark F. Haigh (mfhaigh)
Assigned to: Greg Stein (gstein)
Summary: Compile fix rollup patch against 2.0.0
Initial Comment:
The attached rollup patch fixes the following bugs:
#1414066 - make failes on hpux
#1033965 - Building application fails with Intel C
compiler (1.95.7)
#N/A - Build fails on Tru64 UNIX.
The patch was tested on x86-64 Linux, i386 NetBSD,
HP-UX 11i, and Tru64 5.1b. All tests passed on each
machine.
----------------------------------------------------------------------
>Comment By: Karl Waclawek (kwaclaw)
Date: 2006-12-12 14:17
Message:
Logged In: YES
user_id=290026
Originator: NO
I am preparing for a new release, and I came across this part of your
patch:
-ifndef INSTALL_ROOT
INSTALL_ROOT=$(DESTDIR)
-endif
Why did you remove this logic?
It was added due to bug # 985235 and patch # 779334.
I am inclined to add it back, though some platforms have trouble with it.
(see bug # 1490371). Maybe there is a way to improve it?
Re-opening this issue.
Karl
----------------------------------------------------------------------
Comment By: Karl Waclawek (kwaclaw)
Date: 2006-03-06 09:25
Message:
Logged In: YES
user_id=290026
Patch applied March 6, 2006.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2006-02-27 17:02
Message:
Logged In: NO
You could get really anal and note that the conversion from
a pointer type to an integer type is implementation-defined
by the C standard in the first place. But we all know it
"just works" nearly everywhere.
The code here is broken anyways. And since the value is
never really _used_, it doesn't matter. But changing the
cast to long prevents a warning on all architectures I know
of except for Windows-64, which uses a 32 bit long and 64
bit pointers (LLP64 model).
Using the newer C99 types is preferable, of course, and the
best thing to do is to provide an autoconf-assisted stdint.h
that can be used if the system doesn't have stdint.h. Note
that uintptr_t and friends are optional types under C99 anyways!
But, like I said, all this does is paper-over a
(well-deserved) warning, nothing more.
----------------------------------------------------------------------
Comment By: Karl Waclawek (kwaclaw)
Date: 2006-02-27 09:42
Message:
Logged In: YES
user_id=290026
Actually, it should be uintptr_t or intptr_t, but the
question is, how many compilers recognize these types (were
they not introduced with C99?).
----------------------------------------------------------------------
Comment By: Karl Waclawek (kwaclaw)
Date: 2006-02-27 09:26
Message:
Logged In: YES
user_id=290026
One question about the patch to runtests.c:
- int callno = 1 + (int)XML_GetUserData(parser);
+ long callno = 1 + (long)XML_GetUserData(parser);
Why changing from int to long?
If we really want to be anal, why not change to ptrdiff_t,
as callno hast to fit into a pointer?
----------------------------------------------------------------------
Comment By: Karl Waclawek (kwaclaw)
Date: 2006-02-24 10:16
Message:
Logged In: YES
user_id=290026
Thanks.
Seems to work on Cygwin as well.
Will check it in if Greg has no objections.
----------------------------------------------------------------------
Comment By: Mark F. Haigh (mfhaigh)
Date: 2006-02-23 23:10
Message:
Logged In: YES
user_id=1458985
The patch was against the 2.0.0 release. I'm attaching the
same patch against CVS as of Feb 23, 2006, 8:00 PST.
----------------------------------------------------------------------
Comment By: Karl Waclawek (kwaclaw)
Date: 2006-02-23 22:10
Message:
Logged In: YES
user_id=290026
Is this patch against CVS?
It fails for me on Makefile.in:
$ patch -i compile-rollup.patch -p 1
patching file lib/expat_external.h
patching file Makefile.in
Hunk #3 succeeded at 157 (offset 1 line).
Hunk #4 FAILED at 172.
1 out of 4 hunks FAILED -- saving rejects to file
Makefile.in.rej
patching file tests/minicheck.h
patching file tests/runtests.c
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1437840&group_id=10127
More information about the Expat-bugs
mailing list