[bugs #10791] NSLog() does not support long long int correctly

[Richard Frith-Macdonald]

This mail is an automated notification from the bugs tracker
 of the project: GNUstep.

/**************************************************************************/
[bugs #10791] Latest Modifications:

Changes by: 
                Richard Frith-Macdonald <rfm@gnu.org>
'Date: 
                Mon 11/01/2004 at 08:27 (GMT)

------------------ Additional Follow-up Comments ----------------------------
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).







/**************************************************************************/
[bugs #10791] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=10791>
Project: GNUstep
Submitted by: Fred Kiefer
On: Sun 10/24/2004 at 18:33

Category:  Base/Foundation
Severity:  3 - Ordinary
Item Group:  Bug
Resolution:  None
Privacy:  Public
Assigned to:  CaS
Status:  Open


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 11/01/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: Sun 10/31/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: Sun 10/31/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/