# Re: Integers and standard

*From*: "James Van Buskirk" <not_valid@xxxxxxxxxxx>*Date*: Tue, 29 Jul 2008 15:03:28 -0600

"Steven G. Kargl" <kargl@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message

news:g6nufe$45n$1@xxxxxxxxxxxxxxxxxxxxxxxxxx

The above is consistent with how a BOZ is handled when placed in a

a data statement. If INTEGER(1) is 32-bit and if an INTEGER(2) exists

with larger decimal exponent range, then INT(Z'80000000') will overflow

if you do

INTEGER(1) :: i = INT(Z'80000000')

You seem to be saying that z'80000000' is positive so that converting

it to a signed 32-bit quantity causes overflow, but this seems a bit

imprecise as a description for what happens with gfortran:

C:\gcc_mingw64\clf\ovl>type ovl3.f90

program ovl3

implicit none

integer, parameter :: ik16 = selected_int_kind(38)

integer(ik16) i

! 0 1 2 3 4

! 1234567890123456789012345678901234567890

i = real(z'80000000000000000000000000000000')

write(*,'(z0)') i

end program ovl3

C:\gcc_mingw64\clf\ovl>gfortran ovl3.f90 -oovl3

ovl3.f90:8.47:

i = real(z'80000000000000000000000000000000')

1

Error: Integer too big for integer kind 16 at (1)

real x

x = real(Z'123445678')

end

Should a Fortran processor ignore the leading 1 or the trailing 8 or

assume some 40-bit FP representation with rounding to a 32-bit FP? All

of these are allowed by F2003. gfortran (IMHO) takes the sensible

approach of issuing an error.

troutmask:kargl[203] ~/../sgk/work/4x/bin/gfortran -static -o z g.f90

g.f90:2.12:

x = real(Z'123445678')

1

Error: BOZ constant at (1) is too large (33 vs 32 bits)

But this last behavior is that required by N1723.pdf, section 13.3.3.

Perhaps you should fix it, then :)

--

write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &

6.0134700243160014d-154/),(/'x'/)); end

.

**Follow-Ups**:**Re: Integers and standard***From:*Steven G. Kargl

**Re: Integers and standard***From:*James Van Buskirk

**References**:**Integers and standard***From:*Alfredo Buttari

**Re: Integers and standard***From:*James Van Buskirk

**Re: Integers and standard***From:*Steven G. Kargl

**Re: Integers and standard***From:*Dan Nagle

**Re: Integers and standard***From:*James Giles

**Re: Integers and standard***From:*Steven G. Kargl

- Prev by Date:
**Re: Integers and standard** - Next by Date:
**Re: Integers and standard** - Previous by thread:
**Re: Integers and standard** - Next by thread:
**Re: Integers and standard** - Index(es):