How to store a 13 digit number in c ?

T

Tor Rustad

Max TenEyck Woodbury skrev:
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.

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

Keith Thompson

Tor Rustad said:
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.
 
J

J. J. Farrell

Tor said:
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.
 
C

CBFalconer

J. J. Farrell said:
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.
 
C

Chris McDonald

Clark S. Cox III said:
Chris McDonald wrote:
On any C99 compiler, long long is *always* at least 64-bits. Period.
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.
 
C

Clark S. Cox III

Chris said:
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.
 
T

Tor Rustad

Keith Thompson skrev:
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....tad+64-bit&qt_g=1&searchnow=Search+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.
 
T

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.

:)
 
K

Keith Thompson

Tor Rustad said:
Keith Thompson skrev:


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.
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.
On 64-bit platforms, I would guess the LP64 model is standard, so what?

So some C90 compilers have 64-bit longs.
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 don't see anything there about 64-bit integers in Microsoft
compilers.

[snip]
 
R

Richard Bos

Clark S. Cox III said:
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
 
R

Richard Bos

Jordan Abel said:
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
 
K

Keith Thompson

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.h> doesn't use such types, it doesn't seem like a
big deal.
 
T

Tor Rustad

Keith Thompson skrev:
Tor Rustad said:
Keith Thompson skrev:
[...]
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.

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.

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.

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

Keith Thompson

Tor Rustad said:
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.

[...]
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]
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,444
Messages
2,571,709
Members
48,796
Latest member
Greg L.
Top