Mail Archives: djgpp/2005/11/20/02:31:38
"Martin Ambuhl" <mambuhl AT earthlink DOT net> wrote in message
news:b_Iff.2403$N45 DOT 1990 AT newsread1 DOT news DOT atl DOT earthlink DOT net...
> Rod Pemberton wrote:
> > "Martin Ambuhl" <mambuhl AT earthlink DOT net> wrote in message
> > news:Iayff.1893$wf DOT 1283 AT newsread3 DOT news DOT atl DOT earthlink DOT net...
> >
> >>Rod Pemberton wrote:
> >>
> >>>"Martin Ambuhl" <mambuhl AT earthlink DOT net> wrote in message
> >>>news:Cxvff.2173$N45 DOT 189 AT newsread1 DOT news DOT atl DOT earthlink DOT net...
> >>>
> >>>
> >>>>Scott wrote:
> >>>>
> >>>>
> >>>>>On Fri, 18 Nov 2005 21:03:01 GMT, Martin Ambuhl
<mambuhl AT earthlink DOT net>
> >>>>>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);
> >>>>
> >>>>If you mean an example of undefined behavior. The %llX specifier
> >>>>expects an unsigned long long; (long long)-1 is not unsigned.
> >>>
> >>>
> >>>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);
> >>>
> >>
> >>Wrong. Since the L length modifier specifies that the argument is a
> >>long double, you've found another way to screw things up.
> >
> >
> > No sir, I am correct. You are partially correct.
>
> 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.
(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.
- Raw text -