How to store a 13 digit number in c ?

[Prasad]

Hi,

Can anyone please tell me how to store a 13 digit number in C language
? Also what is the format specifier to be used to access this variable
?

Thanks in advance,
Prasad P

[Richard Heathfield]

Prasad said:

Hi,

Can anyone please tell me how to store a 13 digit number in C language
?

You have two choices:

(1) find a native type that's big enough;
(2) use a non-native representation (either by writing support for it
yourself, or by using existing third-party libraries).

C imposes no upper limits on native numerical types, but in practice those
limits do exist. So it imposes *minimum* upper limits instead, so that you
at least have a fighting chance!

In C90, no native integer type (and I'm guessing that we're talking about
integers here) is required to be able to store 13-decimal-digit numbers,
although all of them are allowed to, so if you are using C90 or are
required to retain portability to C90 implementations, you are stuck with
option (2). Either write your own bignum package, or use something like GMP
or Miracl.

In C99, you can use long long int or its unsigned partner, which must be at
least 64 bits wide (but can be wider), and so they are easily capable of
storing 13-decimal-digit numbers. (But beware! Some C90 compilers also
offer long long int (or an equivalent) as an extension. Doing so does not
magically turn them into C99 compilers.)

Also what is the format specifier to be used to access this variable?

For GMP and Miracl, consult the documentation for techniques for writing the
value to, or reading from, a stream.

For C99's long long int and unsigned long long int, use %lld and %llu
respectively.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[Frederick Gotham]

Prasad:

Can anyone please tell me how to store a 13 digit number in C language
?

You haven't specified the radix of the number system. However, I think it's
safe to assume that you're human and that you've got 10 fingers, so we'll
go with that one for a minute.

I'm not sure if Standard C provides an unsigned integer type which must
have at least 44 value representation bits. (If it does, then it's probably
"int unsigned long long").

I can think of a simple method of achieving what you want (although
somewhat inefficient), which is the use of binary-coded decimal. The radix
must be below 257 for the following to work on any implementation:

(Unchecked code, sloppily written, probably won't even compile.)

#include <limits.h>

#define RADIX (10)
#define DIGIT_BIT (4) /* A better way than hardcoding 4? */
#define DIGIT_PER_BYTE (CHAR_BIT/DIGIT_BIT)

#define DIGIT_BIT_MASK (~(UINT_MAX << DIGIT_BIT))

typedef struct ThirteenDigitNum {
char unsigned digits[13/DIGIT_PER_BYTE + !!(13%DIGIT_PER_BYTE)];
} ThirteenDigitNum;

typdef struct DigitAccessInfo {
unsigned byte_index;
unsigned shift_by;
unsigned mask;
};

void SetDAI(DigitAccessInfo *const p,unsigned const index)
{
p->byte_index = index / DIGIT_PER_BYTE,
p->shift_by = CHAR_BIT * index % DIGIT_PER_BYTE;
p->mask = DIGIT_BIT_MASK << shift_by;
}

unsigned GetDigit(ThirteenDigitNum const *const p,unsigned const index)
{
DigitAccessInfo dai; SetDai(&dai,index);

return (*p->digits[dai.byte_index] & dai.mask) >dai.shift_by;
}

void SetDigit(ThirteenDigitNum const *const p,unsigned const index,
unsigned const val)
{
DigitAccessInfo dai; SetDai(&dai,index);

*p->digits[dai.byte_index] &= ~dai.mask;

*p->digits[dai.byte_index] |= val << dai.shift_by;
}

--

Frederick Gotham

[Tor Rustad]

Prasad skrev:

Hi,

Can anyone please tell me how to store a 13 digit number in C language

char number[14];

? Also what is the format specifier to be used to access this variable

printf("%s", number);
If there is a need to do arithmetic, you need to do radix 256 math, an
example of such is given in "Numerical Recipes in C". More efficient
multi-precision packages exsist, see for example the lip package by
Arjen K. Lenstra. If you want to implement such a package, take a look
in Knuth "TAoCP".

--
Tor <torust AT online DOT no>
"To this day, many C programmers believe that 'strong typing' just
means pounding extra hard on the keyboard". PvdL

[Keith Thompson]

Frederick Gotham <fg*******@SPAM.comwrites:

Prasad:

>Can anyone please tell me how to store a 13 digit number in C language
?

You haven't specified the radix of the number system. However, I think it's
safe to assume that you're human and that you've got 10 fingers, so we'll
go with that one for a minute.

I'm not sure if Standard C provides an unsigned integer type which must
have at least 44 value representation bits. (If it does, then it's probably
"int unsigned long long").

[...]

Everyone else refers to that type as "unsigned long long" or "unsigned
long long int". Drop the "unsigned" if you want to be able to
represent negative numbers.

The language, for some reason, allows you to use the keywords in a
different order. Frederick Gotham is the *only* person I know of who
does this. If you want others to be able to read your code easily,
it's best to follow normal conventions.

And yes, "long long" and "unsigned long long" are guaranteed to be at
least 64 bits. They're standard in C99, and a common (but not
universal) extension in C90 compilers.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[pete]

Keith Thompson wrote:

>
Frederick Gotham <fg*******@SPAM.comwrites:

"int unsigned long long"

Everyone else refers to that type as "unsigned long long" or "unsigned
long long int". Drop the "unsigned" if you want to be able to
represent negative numbers.

The language, for some reason, allows you to use the keywords in a
different order. Frederick Gotham is the *only* person I know of who
does this. If you want others to be able to read your code easily,
it's best to follow normal conventions.

I write (long unsigned) instead of (unsigned long)
to help me to remember to write %lu instead of %ul,
which is a mistake that I've made once or twice.

--
pete

[Keith Thompson]

"Tor Rustad" <to********@hotmail.comwrites:

Prasad skrev:

>Hi,

Can anyone please tell me how to store a 13 digit number in C language

char number[14];

>? Also what is the format specifier to be used to access this variable

printf("%s", number);

If there is a need to do arithmetic, you need to do radix 256 math, an
example of such is given in "Numerical Recipes in C". More efficient
multi-precision packages exsist, see for example the lip package by
Arjen K. Lenstra. If you want to implement such a package, take a look
in Knuth "TAoCP".

If you're going to do radix 256 math, you should declare the array as
unsigned char, not char.

But since 13 decimal digits will fit in less than 64 bits, you should
almost always be able to use plain integer types rather than some
multi-precision package (unless you have a C90 compiler that doesn't
provide a 64-bit integer type, either as an extension or as "long").

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Chris McDonald]

>Frederick Gotham <fg*******@SPAM.comwrites:

"int unsigned long long"

Are you writing for an 8-bit processor, because it wasn't clear
how many bits are provided by your 'long long' construction.
Why not take the little effort, and use an int64_t ?

--
Chris.

[Keith Thompson]

Chris McDonald <ch***@csse.uwa.edu.auwrites:

>>Frederick Gotham <fg*******@SPAM.comwrites:

>"int unsigned long long"

Are you writing for an 8-bit processor, because it wasn't clear
how many bits are provided by your 'long long' construction.
Why not take the little effort, and use an int64_t ?

In any conforming C99 implementation, unsigned long long is guaranteed
to be at least 64 bits.

Many non-C99 implementations provide (unsigned) long long as an
extension. I would expect them to make it at least 64 bits (there's
no point in defining it otherwise) -- and I wouldn't be surprised if
an implementation provided long long but *didn't* provide <stdint.h>
or (u)int64_t. Of course, you can always define (u)int64_t yourself
if the implementation doesn't.

Bottom line: (unsigned) long long is probably more portable than
(u)int64_t, and is very unlikely to be less than 64 bits.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Keith Thompson said:

<snip>

>
Many non-C99 implementations provide (unsigned) long long as an
extension. I would expect them to make it at least 64 bits (there's
no point in defining it otherwise)

IMHO there's no point in defining it /at all/. They can simply make long int
64 bits wide instead. Or more.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[Tor Rustad]

Keith Thompson skrev:

"Tor Rustad" <to********@hotmail.comwrites:

If there is a need to do arithmetic, you need to do radix 256 math, an
example of such is given in "Numerical Recipes in C". More efficient
multi-precision packages exist, see for example the lip package by
Arjen K. Lenstra. If you want to implement such a package, take a look
in Knuth "TAoCP".

If you're going to do radix 256 math, you should declare the array as
unsigned char, not char.

The example in "Numerical Recipes in C" do use unsigned char.

But since 13 decimal digits will fit in less than 64 bits, you should

Most people don't work at a Supercomputer Center... :) Why would OP
ask, if having a C compiler with 64-bit integers?

almost always be able to use plain integer types rather than some
multi-precision package (unless you have a C90 compiler that doesn't
provide a 64-bit integer type, either as an extension or as "long").

When did compiler extensions become on-topic and "long" able to hold a
64-bit integers in c.l.c? *shocked*

I currently use at least 5 different C compilers, none provide a 64-bit
integer type "long long". Also, I checked
http://gcc.gnu.org/c99status.html... not much progress last 3 years
there, which C99 compiler do "almost" everybody use these days?

--
Tor <torust AT online DOT no>
"To this day, many C programmers believe that 'strong typing' just
means pounding extra hard on the keyboard". PvdL

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalidwrites:

Keith Thompson said:
<snip>

>>
Many non-C99 implementations provide (unsigned) long long as an
extension. I would expect them to make it at least 64 bits (there's
no point in defining it otherwise)

IMHO there's no point in defining it /at all/. They can simply make long int
64 bits wide instead. Or more.

Unfortunately, there's a lot of (poorly written) code out there that
makes unwarranted assumptions about the sizes of the predefined types.
Catering to such code is an unfortunate necessity, but it's a
necessity nonetheless.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Max TenEyck Woodbury]

Tor Rustad wrote:

>
When did compiler extensions become on-topic

A long-long time ago. (word play intended!)

and "long" able to hold a 64-bit integers in c.l.c? *shocked*

From the beginning. The standard sets minimums, but not
maximums for the number of bits in each integer type.

I currently use at least 5 different C compilers, none provide a 64-bit
integer type "long long". Also, I checked
http://gcc.gnu.org/c99status.html... not much progress last 3 years
there, which C99 compiler do "almost" everybody use these days?

GCC has had 'long long' for the better part of a decade, if not
longer. Of course it has not changed in the last 3 years.

Now Microsoft on the other hand has been a bit slow on the
uptake, but that is to be expected...

[Richard Heathfield]

Keith Thompson said:

<snip>

Unfortunately, there's a lot of (poorly written) code out there that
makes unwarranted assumptions about the sizes of the predefined types.
Catering to such code is an unfortunate necessity, but it's a
necessity nonetheless.

At least one implementor has demonstrated that 64-bit longs (and ints, and
shorts) are viable.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[Tor Rustad]

Max TenEyck Woodbury skrev:

Tor Rustad wrote:

and "long" able to hold a 64-bit integers in c.l.c? *shocked*

From the beginning. The standard sets minimums, but not
maximums for the number of bits in each integer type.

LONG_MAX... gives the maximum value for "long" in portable C programs.

I used 64-bit "int" 16 years ago on Cray, but that was very much
non-portable, still is, except for someone porting programs among
super-computers. :)

I currently use at least 5 different C compilers, none provide a 64-bit
integer type "long long". Also, I checked
http://gcc.gnu.org/c99status.html... not much progress last 3 years
there, which C99 compiler do "almost" everybody use these days?

GCC has had 'long long' for the better part of a decade, if not
longer. Of course it has not changed in the last 3 years.

Support for "long long", doesn't make it a C99 compiler.

--
Tor <torust AT online DOT no>
"To this day, many C programmers believe that 'strong typing' just
means pounding extra hard on the keyboard". PvdL

[Ian Collins]

Tor Rustad wrote:

Max TenEyck Woodbury skrev:

>>Tor Rustad wrote:

>>>and "long" able to hold a 64-bit integers in c.l.c? *shocked*

From the beginning. The standard sets minimums, but not
maximums for the number of bits in each integer type.

LONG_MAX... gives the maximum value for "long" in portable C programs.

I used 64-bit "int" 16 years ago on Cray, but that was very much
non-portable, still is, except for someone porting programs among
super-computers. :)

64 bit long is the norm on 64 bit desktop/servers these days.

--
Ian Collins.

[Max TenEyck Woodbury]

Tor Rustad wrote:

Max TenEyck Woodbury skrev:

>>Tor Rustad wrote:

>>>and "long" able to hold a 64-bit integers in c.l.c? *shocked*

From the beginning. The standard sets minimums, but not
maximums for the number of bits in each integer type.

LONG_MAX... gives the maximum value for "long" in portable C programs.

Exactly, and the standard specifies a minimum value for it that assures
that 'long' will contain at least 32 bits. Larger values, with more
bits is allowed.

>

>>>I currently use at least 5 different C compilers, none provide a 64-bit
integer type "long long". Also, I checked
http://gcc.gnu.org/c99status.html... not much progress last 3 years
there, which C99 compiler do "almost" everybody use these days?

GCC has had 'long long' for the better part of a decade, if not
longer. Of course it has not changed in the last 3 years.

Support for "long long", doesn't make it a C99 compiler.

scuse please; you brought up GCC and mentioned 'long long' in
relation to it. 'long long' is in the C99 standard. You also
said something about GCC not having changed in 3 years. That
implied that 'long long' was not implemented in GCC. I pointed
out that it had been implemented.

As for GCC being C99 compliant, there have been a few changes
in the last year or so and it does claim to be a C99 compiler
in one of its modes. (-std=c99 or something like that.) They
are not great documenters so I'm not at all surprised that they
have not updated their 'status' page.

Chill...

[J. J. Farrell]

Tor Rustad wrote:

Keith Thompson skrev:

But since 13 decimal digits will fit in less than 64 bits, you should

Most people don't work at a Supercomputer Center... :)

So? Most modern general-purpose computers support 64-bit native
integers, and many high-end ones have for many years. It's well over a
decade since "64-bit int" implied "supercomputer".

Why would OP ask, if having a C compiler with 64-bit integers?

The OP asked how to store a 13 digit number and gave no clue as to the
level of his knowledge. Putting it in a 64-bit integer type is an
obvious way to do it, but there's no reason to believe the OP was aware
of that.

almost always be able to use plain integer types rather than some
multi-precision package (unless you have a C90 compiler that doesn't
provide a 64-bit integer type, either as an extension or as "long").

When did compiler extensions become on-topic and "long" able to hold a
64-bit integers in c.l.c? *shocked*

When c.l.c was created. Why be shocked?

I currently use at least 5 different C compilers, none provide a 64-bit
integer type "long long".

I find that very suprising. Most of the compilers I use provide it.

Also, I checked
http://gcc.gnu.org/c99status.html... not much progress last 3 years
there, which C99 compiler do "almost" everybody use these days?

Almost nobody uses a C99 compiler these days. What made you think
"almost" everybody does?

[Jordan Abel]

2006-11-10 <80U4h.3309$Bk5.3152@trnddc06>,
Max TenEyck Woodbury wrote:

Tor Rustad wrote:

>Max TenEyck Woodbury skrev:

>>>Tor Rustad wrote:

>>>>and "long" able to hold a 64-bit integers in c.l.c? *shocked*

From the beginning. The standard sets minimums, but not
maximums for the number of bits in each integer type.

LONG_MAX... gives the maximum value for "long" in portable C programs.

Exactly, and the standard specifies a minimum value for it that assures
that 'long' will contain at least 32 bits. Larger values, with more
bits is allowed.

>>

>>>>I currently use at least 5 different C compilers, none provide a 64-bit
integer type "long long". Also, I checked
http://gcc.gnu.org/c99status.html... not much progress last 3 years
there, which C99 compiler do "almost" everybody use these days?

GCC has had 'long long' for the better part of a decade, if not
longer. Of course it has not changed in the last 3 years.

Support for "long long", doesn't make it a C99 compiler.

scuse please; you brought up GCC and mentioned 'long long' in
relation to it. 'long long' is in the C99 standard. You also
said something about GCC not having changed in 3 years. That
implied that 'long long' was not implemented in GCC. I pointed
out that it had been implemented.

As for GCC being C99 compliant, there have been a few changes
in the last year or so and it does claim to be a C99 compiler
in one of its modes. (-std=c99 or something like that.) They
are not great documenters so I'm not at all surprised that they
have not updated their 'status' page.

The things that page says don't work, still don't work.

Now, that list is actually quite short:

wide character library support in <wchar.hand <wctype.h(originally
specified in AMD1) (Library Issue, Missing)
variable-length arrays (Broken)
complex (and imaginary) support in <complex.h(Broken)
extended identifiers (Missing)
extended integer types in <stdint.h(Missing)
additional math library functions in <math.h(Library Issue, Missing)
IEC 60559 (also known as IEC 559 or IEEE arithmetic) support (Broken)
inline functions (Broken)
additional predefined macro names (Missing)
standard pragmas (Missing)

And a lot of them are partially supported.

[Clark S. Cox III]

Chris McDonald wrote:

>>Frederick Gotham <fg*******@SPAM.comwrites:

>>>"int unsigned long long"

Are you writing for an 8-bit processor, because it wasn't clear
how many bits are provided by your 'long long' construction.

On any C99 compiler, long long is *always* at least 64-bits. Period.

Why not take the little effort, and use an int64_t ?

Because we don't need it to be *exactly* 64-bits, we just need it to be
*at least* 44-bits.
--
Clark S. Cox III
cl*******@gmail.com

[Tor Rustad]

Max TenEyck Woodbury skrev:

Tor Rustad wrote:

Max TenEyck Woodbury skrev:

>Tor Rustad wrote:

>>and "long" able to hold a 64-bit integers in c.l.c? *shocked*

From the beginning. The standard sets minimums, but not
maximums for the number of bits in each integer type.

LONG_MAX... gives the maximum value for "long" in portable C programs.

Exactly, and the standard specifies a minimum value for it that assures
that 'long' will contain at least 32 bits. Larger values, with more
bits is allowed.

LONG_MAX gives the minimum for C90 (or C99) implementation, but the
_maximum_ for a strictly conforming C program.

That is, from a c.l.c programmer point-of-view this is a *maximum*
limit, unless invoking implementation-defined behavior.

>GCC has had 'long long' for the better part of a decade, if not
longer. Of course it has not changed in the last 3 years.

Support for "long long", doesn't make it a C99 compiler.

scuse please; you brought up GCC and mentioned 'long long' in
relation to it. 'long long' is in the C99 standard.

I replied to this statement by Keith:

"almost always be able to use plain integer types rather than some
multi-precision package (unless you have a C90 compiler..."

after I gave OP a solution.

Quite interesting wording, "almost always"... so now please tell me,
where all these C99 compilers.... or show me a strictly conforming C90
program, using 64-bit integers.

You also said something about GCC not having changed
in 3 years. That implied that 'long long' was not
implemented in GCC.

???

I said "not much progress last 3 years there"... how is that
possiblly similar to "not having changed"?!

As for GCC being C99 compliant, there have been a few changes
in the last year or so and it does claim to be a C99 compiler
in one of its modes. (-std=c99 or something like that.)

This status page was "Last modified 2006-06-21", so unless that
Broken/Missing list is wrong, the GCC team doesn't claim to have a C99
compliant compiler at all.

--
Tor <torust AT online DOT no>
"To this day, many C programmers believe that 'strong typing' just
means pounding extra hard on the keyboard". PvdL

[Keith Thompson]

"Tor Rustad" <to********@hotmail.comwrites:
[...]

I replied to this statement by Keith:

"almost always be able to use plain integer types rather than some
multi-precision package (unless you have a C90 compiler..."

after I gave OP a solution.

Quite interesting wording, "almost always"... so now please tell me,
where all these C99 compilers.... or show me a strictly conforming C90
program, using 64-bit integers.

[...]

There are very few conforming C99 compilers. It's difficult, but not
impossible, for a strictly conforming C90 program to *conditionally*
use 64-bit integers (as long as its output is the same whether 64-bit
integers are available or not).

Please explain where I mentioned "all those C99 compilers", or said
anything about strictly conforming C90 programs.

*Some* C90 compilers have 64-bit longs. *Most* C90 compilers, in my
admittedly incomplete experience, support a 64-bit integer type as an
extension, either by the name "long long" or by some other name (I
vaguely recall that some Microsoft compiler or other supports a 64-bit
integer type but doesn't call it "long long").

If you want absolute portability, meaning that your code must work
properly with all conforming C implementations and may not depend on
any extensions, then you can't store 13-digit numbers without using
some kind of trick such as a multi-precision package. (Such a package
can be implemented in strictly conforming C90.)

But if absolute portability is not a requirement, you can almost
always use a native 64-bit integer type, though it may require a
tangled nest of #ifdefs depending on what platforms you need to
support.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[J. J. Farrell]

Tor Rustad wrote:

>
I replied to this statement by Keith:

"almost always be able to use plain integer types rather than some
multi-precision package (unless you have a C90 compiler..."

after I gave OP a solution.

Quite interesting wording, "almost always"... so now please tell me,
where all these C99 compilers.... or show me a strictly conforming C90
program, using 64-bit integers.

Try reading and quoting Keith's entire sentence, instead of carefully
eliding much of it to change its meaning. We're not that easily taken
in by dirty tactics. Keith did not suggest or imply that there are many
C99 compilers, or that they are widely used.

[CBFalconer]

"J. J. Farrell" wrote:

Tor Rustad wrote:

>>
I replied to this statement by Keith:

"almost always be able to use plain integer types rather than some
multi-precision package (unless you have a C90 compiler..."

after I gave OP a solution.

Quite interesting wording, "almost always"... so now please tell
me, where all these C99 compilers.... or show me a strictly
conforming C90 program, using 64-bit integers.

Try reading and quoting Keith's entire sentence, instead of
carefully eliding much of it to change its meaning. We're not that
easily taken in by dirty tactics. Keith did not suggest or imply
that there are many C99 compilers, or that they are widely used.

In fact I recommend that snipping be done in units of paragraphs,
barring the occasional posting by an illiterate who can only write
in monolythic masses. I tend to just ignore those anyhow.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Chris McDonald]

"Clark S. Cox III" <cl*******@gmail.comwrites:

>Chris McDonald wrote:

>On any C99 compiler, long long is *always* at least 64-bits. Period.

>Why not take the little effort, and use an int64_t ?

>Because we don't need it to be *exactly* 64-bits, we just need it to be
*at least* 44-bits.

OK, thanks;
good luck with your search for something where exactly 64-bits does not
meet your stated requirements.

--
Chris,

[Clark S. Cox III]

Chris McDonald wrote:

"Clark S. Cox III" <cl*******@gmail.comwrites:

>Chris McDonald wrote:

>On any C99 compiler, long long is *always* at least 64-bits. Period.

>>Why not take the little effort, and use an int64_t ?

>Because we don't need it to be *exactly* 64-bits, we just need it to be
*at least* 44-bits.

OK, thanks;
good luck with your search for something where exactly 64-bits does not
meet your stated requirements.

If I have two possible ways to write code, both of which meet my
requirements, and neither is significantly harder to write or read, then
I will always go with the more portable one; even when the difference is
largely academic.

"long long" will meet my requirements, and will be available on *every*
C99 compiler.

"int64_t" will also meet my requirements, but isn't required to be
available on every platform.
--
Clark S. Cox III
cl*******@gmail.com

[Tor Rustad]

Keith Thompson skrev:

"Tor Rustad" <to********@hotmail.comwrites:
[...]

I replied to this statement by Keith:

"almost always be able to use plain integer types rather than some
multi-precision package (unless you have a C90 compiler..."

There are very few conforming C99 compilers. It's difficult, but not
impossible, for a strictly conforming C90 program to *conditionally*
use 64-bit integers (as long as its output is the same whether 64-bit
integers are available or not).

How to conditionally compile 64-bit integers with C90 don't solve it,

you need to handle e.g. ILP32 model as well. In a strictly conforming
program, it's not only difficult to so, but quite impossible.
(remember OP asked for format specifier)

Please explain where I mentioned "all those C99 compilers", or said
anything about strictly conforming C90 programs.

You, critiqued a strictly conforming solution to the problem at hand.
Not only that, but even stated that "almost always" such a
multi-precision solution could be avoided.

As a c.l.c regular, there should be no surprise that you then are
called upon to show an equally conforming solution to the problem.
Furthermore, since I know you cannot provide such a solution with
C90, the logical consequence then was that there now perhaps
was "almost always" a C99 compiler available.

:-)

*Some* C90 compilers have 64-bit longs.

On 64-bit platforms, I would guess the LP64 model is standard, so what?

*Most* C90 compilers, in my
admittedly incomplete experience, support a 64-bit integer type as an
extension, either by the name "long long" or by some other name

This is not the place discuss compiler specific extensions...

Again you repeat this claim that most C90 compilers support
64-bit integers via non-standard extensions, I don't buy it..
can you provide some facts to back up your claim... and no..
you are not allowed to ignore embedded systems.

I consider a more likely event, that DBL_DIG 13, i.e.
a double is able to store this 13-digit number.

(I vaguely recall that some Microsoft compiler or other supports a 64-bit
integer type but doesn't call it "long long").

To refresh your memory, you could try

http://groups.google.no/group/comp.l...rch+this+group

:-)

If you want absolute portability, meaning that your code must work
properly with all conforming C implementations and may not depend on
any extensions, then you can't store 13-digit numbers without using
some kind of trick such as a multi-precision package. (Such a package
can be implemented in strictly conforming C90.)

Exactly.

But if absolute portability is not a requirement, you can almost
always use a native 64-bit integer type, though it may require a
tangled nest of #ifdefs depending on what platforms you need to
support.

If OP was not looking for an ISO C answer, then he came to the
wrong place.

--
Tor <torust AT online DOT no>
"To this day, many C programmers believe that 'strong typing' just
means pounding extra hard on the keyboard". PvdL

[Tor Rustad]

J. J. Farrell skrev:

>
Try reading and quoting Keith's entire sentence, instead of carefully
eliding much of it to change its meaning.

What is your problem? I did read it, and did not snip it to change
the meaning.

We're not that easily taken in by dirty tactics.

I consider off-topic corrections, quite annoying and are *not* used
such a thing from c.l.c regulars. Keith was around long time ago, if
he don't remember me, it's his fault.

Keith did not suggest or imply that there are many
C99 compilers, or that they are widely used.

Kaz and Dan Pop "almost always" made on-topic corrections, since
I expect the same from Keith... it should not be taken as an offense.

:-)

--
Tor <torust AT online DOT no>
"To this day, many C programmers believe that 'strong typing' just
means pounding extra hard on the keyboard". PvdL

[Keith Thompson]

"Tor Rustad" <to********@hotmail.comwrites:

Keith Thompson skrev:

>"Tor Rustad" <to********@hotmail.comwrites:
[...]

I replied to this statement by Keith:

"almost always be able to use plain integer types rather than some
multi-precision package (unless you have a C90 compiler..."

>There are very few conforming C99 compilers. It's difficult, but not
impossible, for a strictly conforming C90 program to *conditionally*
use 64-bit integers (as long as its output is the same whether 64-bit
integers are available or not).

How to conditionally compile 64-bit integers with C90 don't solve it,

you need to handle e.g. ILP32 model as well. In a strictly conforming
program, it's not only difficult to so, but quite impossible.
(remember OP asked for format specifier)

This newsgroup doesn't restrict itself to strictly conforming
programs.

>Please explain where I mentioned "all those C99 compilers", or said
anything about strictly conforming C90 programs.

You, critiqued a strictly conforming solution to the problem at hand.
Not only that, but even stated that "almost always" such a
multi-precision solution could be avoided.

Yes.

As a c.l.c regular, there should be no surprise that you then are
called upon to show an equally conforming solution to the problem.
Furthermore, since I know you cannot provide such a solution with
C90, the logical consequence then was that there now perhaps
was "almost always" a C99 compiler available.

Such a conclusion is possible only if you weren't paying attention to
what I wrote.

The cases are:

(a) A C90 conforming compiler that provides 64-bit long.

(b) A C90 conforming compiler that provides a 64-bit integer type *as
an extension* (either by the name "long long" or by some other name).

(c) A C90 conforming compiler that does not provide any 64-bit integer
type. (This is relatively rare in my experience, but it's certainly
possible. I don't know whether the OP needs to worry about any such
implementations.)

(d) A C99 conforming compiler (that by definition must provide long
long, and must provide an integer type of at least 64 bits). (This is
still rare.)

The C standard explicitly allows extensions. A program that uses such
extensions can still be "conforming", even though it may not be
portable (see C99 4p7).

The fact that some implementations support extensions is certainly
topical; it's explicitly permitted by the standard. The fact that a
particular class of extensions happens to be common is, I suppose,
near the edge of topicality -- but in this case, I was talking about a
class of extensions that are a required feature of C99.

>*Some* C90 compilers have 64-bit longs.

On 64-bit platforms, I would guess the LP64 model is standard, so what?

So some C90 compilers have 64-bit longs.

>*Most* C90 compilers, in my
admittedly incomplete experience, support a 64-bit integer type as an
extension, either by the name "long long" or by some other name

This is not the place discuss compiler specific extensions...

I see nothing wrong with discussing them in general terms.

Again you repeat this claim that most C90 compilers support
64-bit integers via non-standard extensions, I don't buy it..
can you provide some facts to back up your claim... and no..
you are not allowed to ignore embedded systems.

Read carefully what I wrote, particularly the phrase "in my admittedly
incomplete experience". I did not make the claim that you say I did.

I consider a more likely event, that DBL_DIG 13, i.e.
a double is able to store this 13-digit number.

Perhaps, but using floating-point arithmetic to do computations on
integer values is tricky. Doable, but tricky. It wouldn't be my
first choice.

>(I vaguely recall that some Microsoft compiler or other supports a 64-bit
integer type but doesn't call it "long long").

To refresh your memory, you could try

http://groups.google.no/group/comp.l...rch+this+group

:-)

I don't see anything there about 64-bit integers in Microsoft
compilers.

[snip]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Bos]

"Clark S. Cox III" <cl*******@gmail.comwrote:

Chris McDonald wrote:

"Clark S. Cox III" <cl*******@gmail.comwrites:

Chris McDonald wrote:

On any C99 compiler, long long is *always* at least 64-bits. Period.

>Why not take the little effort, and use an int64_t ?

Because we don't need it to be *exactly* 64-bits, we just need it to be
*at least* 44-bits.

OK, thanks;
good luck with your search for something where exactly 64-bits does not
meet your stated requirements.

If I have two possible ways to write code, both of which meet my
requirements, and neither is significantly harder to write or read, then
I will always go with the more portable one; even when the difference is
largely academic.

"long long" will meet my requirements, and will be available on *every*
C99 compiler.

"int64_t" will also meet my requirements, but isn't required to be
available on every platform.

int_least64_t will similarly meet your requirements, will be at least as
small, possibly (though rarely) smaller than long long, and is required
to be available on every platform where long long is required.

Whether you find it more or less readable than long long is a matter of
taste.

Richard

[Richard Bos]

Jordan Abel <ra****@random.yi.orgwrote:

Max TenEyck Woodbury wrote:

As for GCC being C99 compliant, there have been a few changes
in the last year or so and it does claim to be a C99 compiler
in one of its modes. (-std=c99 or something like that.) They
are not great documenters so I'm not at all surprised that they
have not updated their 'status' page.

The things that page says don't work, still don't work.

Now, that list is actually quite short:

variable-length arrays (Broken)
complex (and imaginary) support in <complex.h(Broken)

How broken are these?

extended integer types in <stdint.h(Missing)

Well, that's that for gcc and this thread, then.

Richard

[Keith Thompson]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Jordan Abel <ra****@random.yi.orgwrote:

[...]

>extended integer types in <stdint.h(Missing)

Well, that's that for gcc and this thread, then.

Extended integer types are integer types other than char, short, int,
long, long long, and their signed and unsigned variants; see C99
6.2.5. If <stdint.hdoesn't use such types, it doesn't seem like a
big deal.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Tor Rustad]

Keith Thompson skrev:

"Tor Rustad" <to********@hotmail.comwrites:

Keith Thompson skrev:

"Tor Rustad" <to********@hotmail.comwrites:
[...]
I replied to this statement by Keith:

"almost always be able to use plain integer types rather than some
multi-precision package (unless you have a C90 compiler..."

There are very few conforming C99 compilers. It's difficult, but not
impossible, for a strictly conforming C90 program to *conditionally*
use 64-bit integers (as long as its output is the same whether 64-bit
integers are available or not).

How to conditionally compile 64-bit integers with C90 don't solve it,
you need to handle e.g. ILP32 model as well. In a strictly conforming
program, it's not only difficult to so, but quite impossible.
(remember OP asked for format specifier)

This newsgroup doesn't restrict itself to strictly conforming
programs.

Above, we did very much discuss a strictly conforming solution,
what we do elsewhere is irrelevant.

As a c.l.c regular, there should be no surprise that you then are
called upon to show an equally conforming solution to the problem.
Furthermore, since I know you cannot provide such a solution with
C90, the logical consequence then was that there now perhaps
was "almost always" a C99 compiler available.

Such a conclusion is possible only if you weren't paying attention
to what I wrote.

There was no conclusion above, just what I assumed after
reading your initial response, since you cannot provide
"almost always" a strictly conforming solution via the "very
few" C99 compilers, and only "some" C90 compilers has
64-bit long, your "almost always" boils down to the C90
implementations with support for 64-bit integers as an
extension.

Now, here is my conclusion:

*If* the strictly conforming multi-precision solution *can* be
replaced, it will almost *always* be via a non-standard C90
extensions, which might not be available to OP.

*Most* C90 compilers, in my
admittedly incomplete experience, support a 64-bit integer type as an
extension, either by the name "long long" or by some other name

Again you repeat this claim that most C90 compilers support
64-bit integers via non-standard extensions, I don't buy it..
can you provide some facts to back up your claim... and no..
you are not allowed to ignore embedded systems.

Read carefully what I wrote, particularly the phrase "in my admittedly
incomplete experience". I did not make the claim that you say I did.

OK, I will read the initial statement once more:

"you should almost always be able to use plain integer
types rather than some multi-precision package"

which still looks clear to me, what was I missing?

The "in my admittedly incomplete experience" is not
consistent whith your initial claim.

I consider a more likely event, that DBL_DIG 13, i.e.
a double is able to store this 13-digit number.

Perhaps, but using floating-point arithmetic to do computations on
integer values is tricky. Doable, but tricky. It wouldn't be my
first choice.

Which complication do you have in mind? IMO, it's not very
difficult to store an integer in a double variable, regarding
arithmetic it's mainly division that needs special care.

(I vaguely recall that some Microsoft compiler or other supports
a 64-bit integer type but doesn't call it "long long").

To refresh your memory, you could try

<snip>

I don't see anything there about 64-bit integers in Microsoft
compilers.

Just click on the first thread "64 integers", multiple posts there
has it, including one of mine.

--
Tor <torust AT online DOT no>

[Keith Thompson]

"Tor Rustad" <to********@hotmail.comwrites:

Keith Thompson skrev:

[snip]

Now, here is my conclusion:

*If* the strictly conforming multi-precision solution *can* be
replaced, it will almost *always* be via a non-standard C90
extensions, which might not be available to OP.

And the OP should be able to determine whether that solution is
available to him, and if so whether the loss of portability is
acceptable.

[...]

OK, I will read the initial statement once more:

"you should almost always be able to use plain integer
types rather than some multi-precision package"

which still looks clear to me, what was I missing?

The "in my admittedly incomplete experience" is not
consistent whith your initial claim.

The early parts of this discussion are no longer on my news server,
and I'm not going to take the time to track it down on
groups.google.com. I may have been insufficiently precise in my
initial statement.

In my experience, most current C compilers do support 64-bit integers
in one form or another. The form may or may not be conforming to the
C90 standard, and may or may not be conforming to the C99 standard.
The OP will have to decide (and by this time, probably already has
decided) whether to take advantage of this support if it exists, or to
use a more portable solution that may require extra work.

[...]

>Perhaps, but using floating-point arithmetic to do computations on
integer values is tricky. Doable, but tricky. It wouldn't be my
first choice.

Which complication do you have in mind? IMO, it's not very
difficult to store an integer in a double variable, regarding
arithmetic it's mainly division that needs special care.

I haven't tried that kind of thing much myself, but it seems to me
that there are a number of possible pitfalls. Division, as you point
out, is tricky. Operations that would overflow in integer artithmetic
instead silently lose precision in floating-point. Some operations
("%" and bitwise operations) are not directly available.

And the standard doesn't require DBL_DIG or LDBL_DIG to be greater
than 10, so a program that assumes it can store 13-digit numbers as
floating-point is no more portable than one that assumes it can store
them as integers.

If using floating-point turns out to be the best solution, that's
fine.

[snip]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.