This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Overflow Bug: Regression from Version 4.2.1


On Fri, Jan 9, 2009 at 7:02 AM, Arjen Markus <arjen.markus@wldelft.nl> wrote:
>> On Fri, Jan 9, 2009 at 5:07 AM, Arjen Markus <arjen.markus@wldelft.nl>
>> wrote:
>>>> On Thu, Jan 8, 2009 at 8:45 PM, Tim Prince
>>>> <TimothyPrince@sbcglobal.net>
>>>> wrote:
>> ...
>>> The largest positive integer that will fit into a 4-byte storage using
>>> the usual two's complement scheme is 2**31-1.
>>>
>>> The largest negative integer that fits is -2**31.
>>>
>>> So 2**31 should give an overflow.
>>
>> Thanks, Arjen--I'm obviously rusty binary-wise.
>>
>
> I have simply seen this example before and then had time
> to wonder about it. And I may look at bits and bytes more
> often than the average programmer (I use a lot of binary
> and unformatted files and it helps to be able to "read"
> them as if they were text files - with the aid of
> a hex viewer of course)

Yeah, I forgot that the low-order bit is 2**0, thus the bit positions
are, high to low, 2**31, 2**30, etc.  I stupidly was numbering 1-32,
duh!

So I should have known better: the program causing what I thought was
in error was intentionally using the old force the overflow trick for
a flag; thus the no range check is appropriate.

But I shall make sure the person responsible knows for sure what is
really going on because there is no such error with the Portland
compiler as far as I know (but I'll check).

Thanks again

-Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]