printf() doesn't print long long intege, maybe RHIDE problem
greenberg moshe
printf() do not print long long integer.
It look like RHIDE problem because the size check of the number is ok.
Moshe
Hans-Bernhard Broeker
> printf() do not print long long integer.
It does, if you actually bother to read the documentation to learn how.
--
Hans-Bernhard Broeker (bro...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Martin Ambuhl
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <string.h>
int main(void)
{
long long xll;
size_t i, j, ndx, n = sizeof(long long) / sizeof(int);
int x[n];
char c[sizeof(long long)];
if (sizeof(long long) % sizeof(int)) {
printf
("This example requires sizeof(long long) to be\n"
" a multiple of sizeof(int)\n");
exit(EXIT_FAILURE);
}
srand(time(0));
for (i = 0; i < 5; i++) {
for (ndx = 0, j = 0; j < n; j++, ndx += sizeof(int)) {
x[j] = rand();
memcpy(c + ndx, x + j, sizeof(int));
}
memcpy(&xll, c, sizeof(long long));
printf("Here is a long long: %lld (decimal) %#llx (hex)\n"
"made from these ints (as hex):\n",
xll, (unsigned long long) xll);
for (j = 0; j < n; j++)
printf("%#x ", (unsigned) x[j]);
printf("\n\n");
}
return 0;
}
Here is a long long: 5983791420887767295 (decimal) 0x530ab298040b98ff (hex)
made from these ints (as hex):
0x40b98ff 0x530ab298
Here is a long long: 9081887572752223580 (decimal) 0x7e0958a127ee4d5c (hex)
made from these ints (as hex):
0x27ee4d5c 0x7e0958a1
Here is a long long: 199024756084199939 (decimal) 0x2c313f60fe85203 (hex)
made from these ints (as hex):
0xfe85203 0x2c313f6
Here is a long long: 7037913556498271489 (decimal) 0x61abb11756fc4d01 (hex)
made from these ints (as hex):
0x56fc4d01 0x61abb117
Here is a long long: 1917151184894115895 (decimal) 0x1a9b16d85c554037 (hex)
made from these ints (as hex):
0x5c554037 0x1a9b16d8
Scott
wrote:
>> printf() do not print long long integer.
>Show us how it fails. Here is an example of it working:
<snip example>
Here's another example:
printf("%llX\n", (long long)-1);
-Scott
Martin Ambuhl
If you mean an example of undefined behavior. The %llX specifier
expects an unsigned long long; (long long)-1 is not unsigned.
Rod Pemberton
"Martin Ambuhl" <mam...@earthlink.net> wrote in message
news:Cxvff.2173$N45...@newsread1.news.atl.earthlink.net...
It's probably better to use capital L, instead of ll, since it works with
multiple compilers...
e.g.,
sscanf(s,"%Lx",&value);
printf("%Lu:%Lx\n",prime,counter);
Rod Pemberton
Martin Ambuhl
Wrong. Since the L length modifier specifies that the argument is a
long double, you've found another way to screw things up.
Rod Pemberton
No sir, I am correct. You are partially correct. After my signature, I've
included the relevant text from the C89 final draft, the C99 final draft,
DJGPP's libc.info and OpenWATCOM's c_readme.ihp and clib.ihp. Under C89,
'L' is only defined as "long double" for a, A, e, E, f, F, g, or G. Under
C99, 'L' is only defined as "long double" for a, A, e, E, f, F, g, or G.
Otherwise, for C89 and C99, 'L' is undefined. However, from the relevant
documentation for DJGPP(GCC) and OpenWATCOM, you'll see that for
non-floating point specifiers: b, d, i, o, u, x or X, that 'L' specifies a
"long long".
Rod Pemberton
From C89 4.9.6.1
----
an optional L specifying that a following e , E , f , g , or G conversion
specifier applies to a long double argument. If an h , l , or L appears with
any other conversion specifier, the behavior is undefined.
From C99 7.19.6.1
----
l (ell) Specifies that a following d, i, o, u, x, or X conversion specifier
applies to a long int or unsigned long int argument; that a following n
conversion specifier applies to a pointer to a long int argument; that a
following c conversion specifier applies to a wint_t argument; that a
following s conversion specifier applies to a pointer to a wchar_t argument;
or has no effect on a following a, A, e, E, f, F, g, or G conversion
specifier.
ll (ell-ell) Specifies that a following d, i, o, u, x, or X conversion
specifier applies to a long long int or unsigned long long int argument; or
that a following n conversion specifier applies to a pointer to a long long
int argument.
L Specifies that a following a, A, e, E, f, F, g, or G conversion specifier
applies to a long double argument.
If a length modifier appears with any conversion specifier other than as
specified above, the behavior is undefined
From LIBC.INFO for DJGPP:
----
* An optional conversion qualifier, which may be `h' to specify
`short', `l' to specify long ints, or `L' to specify long doubles.
Long long type can be specified by `L' or `ll'.
From CLIB.IHP and C_README.IHP for OpenWatcom:
----
* "l" causes a "b", "d", "i", "o", "u", "x" or "X" (integer)
conversion to process a long int or unsigned long int argument.
* "l" causes an "n" (converted length assignment) operation to assign
the converted length to an object of type unsigned long int.
* "l" or "w" cause an "s" operation to treat the argument string as a
wide character string (a string composed of characters of type
wchar_t).
* "ll" causes a "b", "d", "i", "o", "u", "x" or "X" (integer)
conversion to process a long long or unsigned long long argument
(e.g., %lld).
* "L" causes a "b", "d", "i", "o", "u", "x" or "X" (integer)
conversion to process an __int64 or unsigned __int64 argument (e.g.,
%Ld).
* "L" causes an "e", "E", "f", "g", "G" (double) conversion to process
a long double argument.
* We have added "long long" (64-bit floating-point) support in the form of
a new __int64 type.
* Better C99 style support for "long long" type is now available in the C
and C++ compilers. LL, ULL and LLU suffixes are recognized for
constants. "long long int" is now also recognized.
Rod Pemberton
> 'L' is only defined as "long double" for a, A, e, E, f, F, g, or G.
Correction, that should have said:
Under C89,
'L' is only defined as "long double" for E, f, F, g, or G.
There is no a,A specifier for C89...
RP
Scott
wrote:
>Scott wrote:
>> printf("%llX\n", (long long)-1);
>
>If you mean an example of undefined behavior. The %llX specifier
>expects an unsigned long long; (long long)-1 is not unsigned.
You know perfectly well what it will actually do on x86, MSDOS and DJGPP.
comp.lang.c.pedantry is down the hall on your left. :)
-Scott
Martin Ambuhl
Come off it. You claimed that
> It's probably better to use capital L, instead of ll, since it works
> with multiple compilers...
This is a gross error. Read what you have quoted from the standard:
> an optional L specifying that a following e , E , f , g , or G conversion
> specifier applies to a long double argument. If an h , l , or L appears with
> any other conversion specifier, the behavior is undefined.
Suggesting replacing a correct standard specifier with one with
undefined behavior which is specific to particular implementations is a
very peculiar way to targer "multiple compilers." You do a real
disservice by doing such and should stop it. Your attempt to justify
this anti-social suggestion contains the very language which shows you
to be wrong.
Joe Wright
Martin, please don't fight this one. From gcc's info on printf..
* An optional conversion qualifier, which may be `h' to specify
`short', `l' to specify long ints, or `L' to specify long doubles.
Long long type can be specified by `L' or `ll'.
Clearly %d is int, %ld is long int and %lld and %Ld are long long int.
These are qualifiers of specifiers, not specifiers themselves. Clearly
%f specifies a double and qualified %Lf a long double.
--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
DJ Delorie
> Martin, please don't fight this one. From gcc's info on printf..
gcc's info on printf is irrelevent. Please read DJGPP's info on
printf:
Scott
>gcc's info on printf is irrelevent. Please read DJGPP's info on
>printf:
>
> http://www.delorie.com/djgpp/doc/libc/libc_624.html
Forgive me if this is an ignorant question, but why does that page say
something different than the docs in djdoc203.zip?
-Scott
Joe Wright
Re-writing history? My quote in the previous message..
* An optional conversion qualifier, which may be `h' to specify
`short', `l' to specify long ints, or `L' to specify long doubles.
Long long type can be specified by `L' or `ll'.
..is copy/pasted from my djgpp 203 [gcc.exe (GCC) 3.1] from 2002 or so.
I intend to refresh my C stuff with the latest djgpp within the next few
weeks. Do you suppose that 'info libc' and then 'g' 'printf' will say
something else?
DJ Delorie
> ..is copy/pasted from my djgpp 203 [gcc.exe (GCC) 3.1] from 2002 or
> so. I intend to refresh my C stuff with the latest djgpp within the
> next few weeks. Do you suppose that 'info libc' and then 'g'
> 'printf' will say something else?
It depends on what verson of djgpp you get. The CVS version of
DJGPP's documentation matches the web version, so you should not use
"%Ld". The printf source code happens to support it, for people who
don't read the directions. %Ld is not standard.
Rod Pemberton
(I'll ignore the fact that your logic is an almost word for word "rehash" of
Michal Necasek's in other conversations on openwatcom.users.c_cpp... Did you
copy? tsk,tsk...)
1) If that logic was accurate, you should be criticizing HIM (i.e, not ME)
for using DJGPP instead of a 100% ANSI C99 compiler. In fact, it is ironic
that you are so adamant about ANSI specifications, since you should know
that probably 40% of DJGPP code is MS-DOS specific (i.e., non-ANSI) and
probably 20% of DJGPP is *NIX specific (i.e, non-ANSI). Although the GCC
info documents have stated compliance with various standards, it's
completely clear from the numerous problems originally listed on the GCC C99
compliance pages, that GCC made little or no attempt whatsoever to comply
with any ANSI/ISO/IEEE specifications until recently. Their compliance was
happenstance at best.
2) The second problem with your argument is that it ignores historical
context. I don't know when or where the usage of "%L" for long long began,
but it predates ANSI's C99 "%ll" by at least three years since the 1996
Linux Manpage for printf has it. And, I doubt that Linux users initiated
it's usage. It was probably adopted from some other *NIX which means it
could have been in use much earlier. Most compilers are just now becoming
C99 compliant, which means that "%L" has been in use for at least ten years
before "%ll". Also, with the success of GCC's "viralware" license, I
wouldn't doubt it if the usage is widespread (perhaps in the next standard
anyone?).
3) The third problem with your argument is that "%L" works. I've never had
a problem with it on the PC, or Stratus Continuum's, or... (well, I can't
completely remember for DEC Vaxen.) Early on, "%ll" was harder to implement
than "%L" (messed up the grammar) and many compilers didn't do so for a long
long time... A prime example of this is WATCOM. "%L" was available in
WATCOM 11.0, but "%ll" wasn't added until OpenWATCOM 1.2, seven versions and
many years later. Microsoft's MSVC doesn't have "%ll" or "%L" they use
"I32" and "I64". So much for the "standards" regarding printf format
specifiers you are so concerned about...
4) The fourth problem with your argument is that you treat C as a static
i.e., dead, language. C is a dynamic language which adapts. It started out
completely typeless (i.e., like FORTH) as BCPL, or some other proto
language, and was modified as needed. The original operators were in this
format: =+ =- =/ ,etc...versus += -= /=, etc... They were eventually
reversed because syntax parsers had problems.
Rod Pemberton
Linux Manpage 28 January 1996 2
PRINTF(3) Linux Programmer's Manual PRINTF(3)
The optional character l (ell) specifying that a
following d, i, o, u, x, or X conversion applies to
a pointer to a long int or unsigned long int argu-
ment, or that a following n conversion corresponds
to a pointer to a long int argument. Linux pro-
vides a non ANSI compliant use of two l flags as a
synonym to q or L. Thus ll can be used in combina-
tion with float conversions. This usage is, how-
ever, strongly discouraged.
The character L specifying that a following e, E,
f, g, or G conversion corresponds to a long double
argument, or a following d, i, o, u, x, or X con-
version corresponds to a long long argument. Note
that long long is not specified in ANSI C and
therefore not portable to all architectures.
Martin Ambuhl
> (I'll ignore the fact that your logic is an almost word for word "rehash" of
> Michal Necasek's in other conversations on openwatcom.users.c_cpp... Did you
> copy? tsk,tsk...)
I will not ignore your innuendos about my intellectual honesty. For
what it's worth, I have never before heard of Michal Necasek or
openwatcom.user.c_cpp. Tsk, tsk on your attempt to trash me with no
evidence. Goodbye.,
*PLONK*