integer overflow

[Eric Sosman]

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

 

[Dan Pop]

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

 

[Eric Sosman]

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

 

[Dan Pop]

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

 

[RoSsIaCrIiLoIA]

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!");
}

 

[RoSsIaCrIiLoIA]

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] )
?