| John Harper 2005-08-21, 9:56 pm |
| In article <dae5jb$tkk$1@news.nems.noaa.gov>,
Paul Van Delst <paul.vandelst@noaa.gov> wrote:[color=darkred]
>perseus wrote:
Sorry to take over a month to follow this up, but I tried inserting
CONTAINS followed by Paul's function in James Van Buskirk's program,
and then using it as follows:
PROGRAM endian
IMPLICIT NONE
INTEGER, PARAMETER :: ik1 = SELECTED_INT_KIND(2)
INTEGER, PARAMETER :: ik4 = SELECTED_INT_KIND(9)
IF(btest(transfer(int((/1,0,0,0/),ik1),1_ik4),0)) THEN
WRITE(*,*) 'James Van Buskirk''s method: LITTLE ENDIAN'
ELSE
WRITE(*,*) 'James Van Buskirk''s method: BIG ENDIAN'
END IF
IF(Big_Endian())THEN
PRINT*,'Paul Van Delst''s method: BIG ENDIAN'
ELSE
PRINT*,'Paul Van Delst''s method: LITTLE ENDIAN'
END IF
CONTAINS
FUNCTION Big_Endian()
INTEGER, PARAMETER :: Short = SELECTED_INT_KIND(4)
INTEGER( Short ) :: Source = 1_Short
LOGICAL :: Big_Endian
Big_Endian = .FALSE.
IF ( iachar( transfer( Source, 'a' ) ) == 0 ) Big_Endian = .TRUE.
END FUNCTION Big_Endian
END PROGRAM endian
Compaq's own f95 version V5.5 on a Compaq machine gave this result:
James Van Buskirk's method: LITTLE ENDIAN
Paul Van Delst's method: LITTLE ENDIAN
With NAG f95 release 4.2 on the same machine the methods disagreed:
James Van Buskirk's method: BIG ENDIAN
Paul Van Delst's method: LITTLE ENDIAN
Maybe there's a bug in the NAG f95 compiler, but if not, it would
seem that at least one of the methods may be:
1. testing something else as well as endianness, or
2. using a processor-dependent feature, or
3. violating the f95 standard.
What's the correct explanation?
John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
|