Re: BOZ literal constants, a puzzle for us Standard-loving types.

Toon Moene wrote:
Program:

$ cat bozlitconst.f
program test
integer i
data i / z'FFFF8000' /
print *, i
end

$ /usr/rel/bin/gfortran -c bozlitconst.f
bozlitconst.f:3.26:

data i / z'FFFF8000' /
1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1)

Note that, in F2003, this will also apply to INT(z'FFFF8000'). It's not just something that happens with DATA statements.

Question to my fellow J3 Committee members: Did we really mean to outlaw this (it has an obvious meaning: stuff the 32 bits that FFFF8000 hex represents into a 32 bit integer and "damn the torpedo's".

g77 accepts it without even warning about it, so this probably means most compilers accept it (g77 was rather late to the game and, consequently, a follower of fashion).

IIRC, g77 is doing rather weird things with it, actually, since it's interpreting the z'FFFF8000' as an integer constant and then converting it. I wouldn't be surprised to find that it's assigning it to an 8-byte integer and then simply wrapping it without throwing an error when it gets assigned to i.

My interpretation would be that the standard isn't, per se, outlawing this _as an extension_. The behavior when an integer is out of range is undefined, and I think it would not be amiss for a compiler to adjust its range-checking to allow for this usage as a special case, considering assignments from a BOZ-literal to an integer to be out of range only when there are too many bits.

But, yeah, I would agree that this is a defect in the standard, that integer constants -- which are how most people store bitwise things! -- don't seem to follow the "treat BOZ-literals as a bitwise representation" rule.

- Brooks


--
The "bmoses-nospam" address is valid; no unmunging needed.
.