delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2005/11/19/04:01:01

X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: "Rod Pemberton" <donthave AT noreply DOT bit>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: printf() doesn't print long long intege, maybe RHIDE problem
Date: Sat, 19 Nov 2005 03:47:35 -0500
Organization: Aioe.org NNTP Server
Lines: 122
Message-ID: <dlmoqh$t6e$1@domitilla.aioe.org>
References: <437d9a13 AT news DOT bezeqint DOT net> <9krff.1763$wf DOT 538 AT newsread3 DOT news DOT atl DOT earthlink DOT net> <437e55e2 DOT 279951667 AT localhost> <Cxvff.2173$N45 DOT 189 AT newsread1 DOT news DOT atl DOT earthlink DOT net> <dlm8uk$elj$1 AT domitilla DOT aioe DOT org> <Iayff.1893$wf DOT 1283 AT newsread3 DOT news DOT atl DOT earthlink DOT net>
NNTP-Posting-Host: pCFjXAYAthfOLF6YhIh1ZA.905.domitilla.aioe.org
X-Complaints-To: abuse AT aioe DOT org
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Priority: 3
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MSMail-Priority: Normal
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

"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.  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.






- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019