This mail is an automated notification from the bugs tracker
of the project: GNUstep.
/**************************************************************************/
[bugs #10791] Latest Modifications:
Changes by:
Fred Kiefer <[EMAIL PROTECTED]>
'Date:
Mon 01.11.2004 at 13:21 (GMT)
What | Removed | Added
---------------------------------------------------------------------------
Resolution | None | Fixed
Status | Open | Closed
------------------ Additional Follow-up Comments ----------------------------
That black magic of moving the include statements did the trick! The long long number
is now outputed correctly on my system.
Thank you!
/**************************************************************************/
[bugs #10791] Full Item Snapshot:
URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=10791>
Project: GNUstep
Submitted by: Fred Kiefer
On: Son 24.10.2004 at 18:33
Category: Base/Foundation
Severity: 3 - Ordinary
Item Group: Bug
Resolution: Fixed
Privacy: Public
Assigned to: CaS
Status: Closed
Summary: NSLog() does not support long long int correctly
Original Submission: While debugging the output of a keyed decoding conversion from
binary to XML, which did not handle a long long int value correctly I noticed that
NSLog() does not handle this type correctly using %lli as template. Looks like
the value gets treated as an int.
I tried the same with printf() and this gave the correct output. I am using SuSE Linux
9.1 on Intel hardware.
Follow-up Comments
------------------
-------------------------------------------------------
Date: Mon 01.11.2004 at 13:21 By: Fred Kiefer <FredKiefer>
That black magic of moving the include statements did the trick! The long long number
is now outputed correctly on my system.
Thank you!
-------------------------------------------------------
Date: Mon 01.11.2004 at 08:27 By: Richard Frith-Macdonald <CaS>
I have tried moving around the order of including headers in GSFormat.m to
exactly mirror the way it's done in the autoconf tests ...
hopefully this will fix things on your system (as you report that the autoconf test
produces the correct result).
-------------------------------------------------------
Date: Son 31.10.2004 at 17:53 By: Fred Kiefer <FredKiefer>
I also think that it is a system specific problem, but not that easy this time. It
used to be the case that LONG_LONG_MAX was not found on SuSE systems, but we already
corrected this and config.log correctly reports that it is found (LLONG_MAX isn't
found).
In config.h I see the line:
#define HANDLE_LONG_LONG_MAX 1
We need another idea, what may go wrong here. Or perhaps this constant is found in the
confic code, beacuse we use
#define _GNU_SOURCE
and a similar line is missing, when the constant gets used? But than the compiler
should complain about a missing definition. No, just checked GSFormat.m has this
define as well.
-------------------------------------------------------
Date: Son 31.10.2004 at 10:01 By: Richard Frith-Macdonald <CaS>
I'm afraid this looks like a system specific problem.
I thing the configure.ac and/or the code in GSFormat.m is failing to find a definition
of LONG_LONG_MAX on your system for some reason.
Please could you check this ...
If I've guessed the problem correctly, and you can figure out why the define is not
being found, we can include the appropriate fields or define whatever other
preprocessor constants we need to have it work on suse.
For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=10791>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-gnustep mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
