integer overflow

[Ashutosh Iddya]

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.

Thanking you.

Ashutosh

[Eric Sosman]

Dan Pop wrote:

In <40************ ***@sun.com> Eric Sosman <Er*********@su n.com> writes:

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.

--
Er*********@sun .com

[Dan Pop]

In <40************ ***@sun.com> Eric Sosman <Er*********@su n.com> writes:

Dan Pop wrote:

In <40************ ***@sun.com> Eric Sosman <Er*********@su n.com> writes:

>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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Eric Sosman]

Dan Pop wrote:

In <40************ ***@sun.com> Eric Sosman <Er*********@su n.com> writes:

Dan Pop wrote:

In <40************ ***@sun.com> Eric Sosman <Er*********@su n.com> writes:

>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 "compatibil ity" 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 ...

--
Er*********@sun .com

[Dan Pop]

In <40************ ***@sun.com> Eric Sosman <Er*********@su n.com> writes:

Dan Pop wrote:

In <40************ ***@sun.com> Eric Sosman <Er*********@su n.com> writes:

>Dan Pop wrote:
>>
>> In <40************ ***@sun.com> Eric Sosman <Er*********@su n.com> writes:
>>
>> >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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[RoSsIaCrIiLoIA]

On Sat, 17 Apr 2004 +1000, "Peter Nilsson" <ai***@acay.com .au> wrote:

"Ashutosh Iddya" <as************ @news.edu.au> wrote in message
news:40******* *************** *@freenews.iine t.net.au...

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]

On Sat, 17 Apr 2004 12:02:41 +1000, "Peter Nilsson"
<ai***@acay.com .au> wrote:

"Arthur J. O'Dwyer" <aj*@nospam.and rew.cmu.edu> wrote in message
news:Pi******* *************** *************@u nix48.andrew.cm u.edu...

On Sat, 17 Apr 2004, Peter Nilsson wrote:

>
> "Ashutosh Iddya" <as************ @news.edu.au> wrote...
> >
> > 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] )
?