scan: which format for a long long int

[__frank__]

Which format I have to use in scanf,
to format a long long int (64bits int
__int64 in MS VC++).
Thanks in advance

 

[Keith Thompson]

Which format I have to use in scanf,
to format a long long int (64bits int
__int64 in MS VC++).

"%lld", if your library supports it. It's required by C99, but of
course there was long long type in C90.

 

[Michael Mair]

Which format I have to use in scanf,
to format a long long int (64bits int
__int64 in MS VC++).
Thanks in advance

"%lld" or "%lli".

Note: The long long integer types are in the language since C99;
AFAIK, MS VC will not fully support C99 even in their 2005 Studio.
At least in VC++6, the semantics of the 64 bit types were partially
broken.
If the above format does not work, you have a 64 bit type as an
implementation specific extension; the format should be specified
in the online help. Otherwise, you may have to ask in a newsgroup
or forum where your implementation is topical.

BTW: If you try to keep your code conforming, you can #define
the appropriate integer conversion format strings and work with
them like that:

#if (defined __STDC_VERSION__) && __STDC_VERSION__ >= 199901L
# define MY_SLLFORMAT "%lld"
# define MY_ULLFORMAT "%llu"
#elif ...... /* ask for your implementation */
...../* Define your implementation specific MY_SLLFORMAT etc here */
#else
# error Cannot define an appropriate 64 bit integer format
#end

.....
printf("Tit (" MY_SLLFORMAT ") for tat\n", mylonglongvar);


Cheers
Michael

 

[Michael Mair]

"%lld", if your library supports it. It's required by C99, but of
course there was long long type in C90.

^
no

Cheers
Michael

 

[Keith Thompson]

^
no

Whoops! Thanks.

 

[Jordan Abel]

"%lld" or "%lli".

Note: The long long integer types are in the language since C99;
AFAIK, MS VC will not fully support C99 even in their 2005 Studio.
At least in VC++6, the semantics of the 64 bit types were partially
broken.
If the above format does not work, you have a 64 bit type as an
implementation specific extension; the format should be specified
in the online help. Otherwise, you may have to ask in a newsgroup
or forum where your implementation is topical.

BTW: If you try to keep your code conforming, you can #define
the appropriate integer conversion format strings and work with
them like that:

#if (defined __STDC_VERSION__) && __STDC_VERSION__ >= 199901L
# define MY_SLLFORMAT "%lld"
# define MY_ULLFORMAT "%llu"
#elif ...... /* ask for your implementation */
..../* Define your implementation specific MY_SLLFORMAT etc here */
#else
# error Cannot define an appropriate 64 bit integer format
#end

....
printf("Tit (" MY_SLLFORMAT ") for tat\n", mylonglongvar);


Cheers
Michael

Usually when defining a macro for a format specifier you don't want
to include the % sign, so as to allow the user to include field
widths and so on

for example

#define PRIdLLONG "lld"
#define PRIuLLONG "llu"

printf("Here's an example with a field width: %10"PRIdLLONG"\n", var);


[i don't know if the entire PRI*/SCN* set of identifiers are
reserved if inttypes.h is included - however if his system has
inttypes.h he should probably be using the types defined therein
instead]

 

[kaikai]

__frank__ 写é“：

Which format I have to use in scanf,
to format a long long int (64bits int
__int64 in MS VC++).
Thanks in advance

In MS VC++, '__int64' read by this way
__int64 i;
scanf("%I64d", &i);

 

[Keith Thompson]

__frank__ 写é“：
In MS VC++, '__int64' read by this way
__int64 i;
scanf("%I64d", &i);

And *only* (as far as I know) in MS VC++. "%I64d" is non-standard and
non-portable. Writing non-portable code is sometimes necessary, of
course.

 

[Michael Mair]

Usually when defining a macro for a format specifier you don't want
to include the % sign, so as to allow the user to include field
widths and so on

for example

#define PRIdLLONG "lld"
#define PRIuLLONG "llu"

printf("Here's an example with a field width: %10"PRIdLLONG"\n", var);

Thank you -- I did not think of this at that moment

Cheers
Michael

 

[websnarf]

And *only* (as far as I know) in MS VC++. "%I64d" is non-standard and
non-portable. Writing non-portable code is sometimes necessary, of
course.

It is also supported by WATCOM C/C++, Borland C, and the Alpha
compiler. This, presumably, is why C99 included stdint.h, and
inttypes.h which includes abstractions for all these things.

The only problem, of course, is that nobody seriously supports C99. So
as a stop gap, you can use pstdint.h available here:

http://www.pobox.com/~qed/pstdint.h

This file can be used by older compilers that don't have even partial
support for C99, and possible don't support 64 bit integers at all (you
can test for this with a #ifdef INT64_MAX in your code.)

This file includes a slightly different abstraction for print modifiers
than inttypes.h -> The macro PRINTF_INT64_MODIFIER is used to specify
the 64bit prefix for the integer formats. So:

"%" PRINTF_INT64_MODIFIER "d"

is (usually) the same as "%lld" or "%I64d" depending on which compiler
you are using.

 

[Emmanuel Delahaye]

Jordan Abel a écrit :

Usually when defining a macro for a format specifier you don't want
to include the % sign, so as to allow the user to include field
widths and so on

Good point. Well noted.

 

[Emmanuel Delahaye]

Keith Thompson a écrit :

And *only* (as far as I know) in MS VC++. "%I64d" is non-standard and
non-portable. Writing non-portable code is sometimes necessary, of
course.

The question is not about the compiler or the IDE, but about the
library. If your linker uses a library that loads the MSVCRT DLL, you
are cooked. (VC++6, of course, but also Dev-C++ and more generally mingw
based IDEs)

 

[Greg Comeau]

It is also supported by WATCOM C/C++, Borland C, and the Alpha
compiler. This, presumably, is why C99 included stdint.h, and
inttypes.h which includes abstractions for all these things.

The only problem, of course, is that nobody seriously supports C99.

Comeau and Dinkumware do. The industry is another story.
Comeau and Dinkumware also support MSisms well too.

 

[Jalapeno]

Comeau and Dinkumware do. The industry is another story.
Comeau and Dinkumware also support MSisms well too.

IBM does too for its z/OS mainframe C

http://publibz.boulder.ibm.com/cgi-.../FRONT_3.2.4?SHELF=CBCBS160&DT=20050628150638


+------------------------------------------------------------------------------+



z/OS XL C compiler specific features

In addition to the features common to z/OS XL C and XL C++, the z/OS XL
C compiler provides you with the following capabilities:


The ability to write portable code that supports the following
standards:

| ISO/IEC 9899:1999 <-----<< isn't this C99?

ANSI/ISO 9899:1990[1992] (formerly ANSI X3.159-1989 C)

X/Open Specification Programming Languages, Issue 3, Common Usage C

FIPS-160


System programming capabilities, which allow you to use z/OS XL C in
place of assembler

Extensions of the standard definitions of the C language to provide
programmers with support for the z/OS environment, such as fixed-point
(packed) decimal data support

 

[Greg Comeau]

IBM does too for its z/OS mainframe C
...
| ISO/IEC 9899:1999 <-----<< isn't this C99?

Yes. I've posted years ago which compilers support and/or
claim to support C99; those posts should be googleable. The point
is still that the industry is not doing a wideapread adoption
of it. I still believe it will be C++ which will popularize C99,
oddly enough, and perhaps not for the better.

 

[Dave Thompson]

On Sat, 29 Oct 2005 09:51:23 +0000 (UTC), Jordan Abel

Usually when defining a macro for a format specifier you don't want
to include the % sign, so as to allow the user to include field
widths and so on

for example

#define PRIdLLONG "lld"
#define PRIuLLONG "llu"

printf("Here's an example with a field width: %10"PRIdLLONG"\n", var);


[i don't know if the entire PRI*/SCN* set of identifiers are
reserved if inttypes.h is included - however if his system has
inttypes.h he should probably be using the types defined therein
instead]

They ({PRI,SCN}[a-zX].*) are; 7.26.4.

- David.Thompson1 at worldnet.att.net