integer overflow

E

Eric Sosman

Dan said:
In said:
Grumble said:
[...]
For my information, are there implementations where double is wider
than 64 bits? ^^^^^^

VAX H-format floating point had/has 128 bits; I don't recall
how they're divided up between exponent and fraction. Also,
when I was working with VAXen the C implementations were not
able to use H-format.

So, you're providing a non-example. long double would have been the
right type for the VAX H_FLOAT type, [...]

Could have been, yes -- except that VAX C predated the
1989 ANSI C Standard and had no `long double' type.
 
D

Dan Pop

In said:
Dan said:
In said:
Grumble wrote:
[...]
For my information, are there implementations where double is wider
than 64 bits? ^^^^^^

VAX H-format floating point had/has 128 bits; I don't recall
how they're divided up between exponent and fraction. Also,
when I was working with VAXen the C implementations were not
able to use H-format.

So, you're providing a non-example. long double would have been the
right type for the VAX H_FLOAT type, [...]

Could have been, yes -- except that VAX C predated the
1989 ANSI C Standard and had no `long double' type.

Guess what? VAX C survived the 1989 ANSI C Standard, therefore it could
have used long double for this purpose.

Dan
 
E

Eric Sosman

Dan said:
In said:
Dan said:
Grumble wrote:
[...]
For my information, are there implementations where double is wider
than 64 bits? ^^^^^^

VAX H-format floating point had/has 128 bits; I don't recall
how they're divided up between exponent and fraction. Also,
when I was working with VAXen the C implementations were not
able to use H-format.

So, you're providing a non-example. long double would have been the
right type for the VAX H_FLOAT type, [...]

Could have been, yes -- except that VAX C predated the
1989 ANSI C Standard and had no `long double' type.

Guess what? VAX C survived the 1989 ANSI C Standard, therefore it could
have used long double for this purpose.

VAX C "survived," but never adopted the Standard.
Digital presumably felt that getting the pre-Standard
compiler to handle a redefined language risked too much
breakage to existing code.

So Digital continued to "support" VAX C while bringing
out an entirely new "DEC C" compiler, Standard-conforming
(modulo bugs and the usual pettifogging) but not burdened
with the problems of backward compatibility. DEC C, of
course, supported `long double` -- but IIRC it was identical
to plain `double' in all but name, and there was still no
support for VAX H-format.

DEC C also ran on the then-new Alpha machines, where
VAX H-format was not available. But "compatibility" doesn't
seem to have been the reason for non-support of H; after
all, DEC C on Alpha had support[*] for IEEE single- and
double-precision floating-point that wasn't available on VAX.

[*] I recall one early version of the DEC C libraries
in which the printf() family couldn't render IEEE
`double' correctly. It seemed that the IEEE numbers
were mis-interpreted as VAX G-format, also 64 bits
but with a different layout ...
 
D

Dan Pop

In said:
Dan said:
In said:
Dan Pop wrote:


Grumble wrote:
[...]
For my information, are there implementations where double is wider
than 64 bits? ^^^^^^

VAX H-format floating point had/has 128 bits; I don't recall
how they're divided up between exponent and fraction. Also,
when I was working with VAXen the C implementations were not
able to use H-format.

So, you're providing a non-example. long double would have been the
right type for the VAX H_FLOAT type, [...]

Could have been, yes -- except that VAX C predated the
1989 ANSI C Standard and had no `long double' type.

Guess what? VAX C survived the 1989 ANSI C Standard, therefore it could
have used long double for this purpose.

VAX C "survived," but never adopted the Standard.

Never fully adopted the standard. It contained plenty of extensions to
K&R C and I don't remember whether long double was among them.
Digital presumably felt that getting the pre-Standard
compiler to handle a redefined language risked too much
breakage to existing code.

So Digital continued to "support" VAX C while bringing
out an entirely new "DEC C" compiler, Standard-conforming
(modulo bugs and the usual pettifogging) but not burdened
with the problems of backward compatibility. DEC C, of
course, supported `long double` -- but IIRC it was identical
to plain `double' in all but name, and there was still no
support for VAX H-format.

So, you're confirming yourself that your original reply had exactly zilch
to do with Grumble's question.

Dan
 
R

RoSsIaCrIiLoIA

Ashutosh Iddya said:
Hi ,

I am performing an integer count of a particular operation in my program.
After a sufficiently large value an overflow occurs. At the moment I have
gone around the problem by declaring it as a double, even that has its
limits. Is there a method of preventing this overflow or some method of
recovering from it. Any help in this regard would be greatly appreciated.

unsigned long counter[2] = { 0 };

for (;;)
{
if (++counter[0] && ++counter[1])
puts("64+ bit counter overflowed!");
}

unsigned long counter[2] = { 0 };

for( ; ; )
{
if( ++counter[0] || ++counter[1] ) ;
else puts("64+ bit counter overflowed!");
}
 
R

RoSsIaCrIiLoIA

Arthur J. O'Dwyer said:
I am performing an integer count of a particular operation in my
program. After a sufficiently large value an overflow occurs. At
the moment I have gone around the problem by declaring it as a
double, even that has its limits. Is there a method of preventing
this overflow or some method of recovering from it. Any help in
this regard would be greatly appreciated.

unsigned long counter[2] = { 0 };

for (;;)
{
if (++counter[0] && ++counter[1])

ITYM if (!(++counter[0] || ++counter[1]))

Or...

if (++counter[0] == 0 && ++count[1] == 0)

or if( !++counter[0] && !++counter[1] )
?
 

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
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top