printing octal

[sh...@ucar.edu]

A question concerning printing octal via fortran:

a = 1.
write (*,"(10x, f9.5)" ) a
write (*,"( 1x, o20)" ) a

produces:

f90 IRIX :

1.00000
7740000000

f90 SunOS system:

1.00000
7740000000

g95 Mac OSX:

1.00000
At line 5 of file tmp.f (Unit 6)
Traceback: not available, compile with -ftrace=frame or -ftrace=full
Fortran runtime error: Expected INTEGER for item 1 in formatted
transfer, got REAL
( 1x, o20)
^
=====

I looked in my office f90 books and see very little on 'octal
printing'.

Is this a bug in g95, in which case I will send to Andy Vaught?
or
Are the SunOD and SGI/IRIX compilers providing a language extension?
or
Is this one of those thing that is not explicitly addressed in the
standard?

THX

[Brooks Moses]

sh...@ucar.edu wrote:
> A question concerning printing octal via fortran:
>
> a = 1.
> write (*,"(10x, f9.5)" ) a
> write (*,"( 1x, o20)" ) a
>
> produces:

[...]

> Is this a bug in g95, in which case I will send to Andy Vaught?
> or
> Are the SunOD and SGI/IRIX compilers providing a language extension?
> or
> Is this one of those thing that is not explicitly addressed in the
> standard?

The standard explicitly states that, for an "O" edit descriptor, the
corresponding input/output list item shall be of type integer.

The SunOS and IRIX compilers are providing an extension. (It's actually
reasonably clear that they are -- anything which produces a result that
indicates the machine's internal representation, as a result of
"7740000000" for a value of 1.0 obviously is, is virtually always a
compiler extension.)

You should be able to get the same results, using standard Fortran, with
the one Fortran function that does deal with the internal representation:

a = 1.
write (*,"(10x, f9.5)" ) a

write (*,"( 1x, o20)" ) transfer(a, 0)

Note that this requires that a and 0 (a default integer) have the same
bit-size, which will be true so long as a is a default real (not double
precision), and you aren't using compiler options that do weird things
with the sizes of default reals and integers.

- Brooks

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

[Richard Maine]

<sh...@ucar.edu> wrote:

> A question concerning printing octal via fortran:
>
> a = 1.
> write (*,"(10x, f9.5)" ) a
> write (*,"( 1x, o20)" ) a

> Fortran runtime error: Expected INTEGER for item 1 in formatted
> transfer, got REAL

> I looked in my office f90 books and see very little on 'octal
> printing'.

If they don't describe the O edit descriptor, then ask for your money
back. :-) They should. However, you might have missed it because it is
described under the integer edit descriptors... which is to say...

> Is this a bug in g95, in which case I will send to Andy Vaught? or Are the
> SunOD and SGI/IRIX compilers providing a language extension? or Is this
> one of those thing that is not explicitly addressed in the standard?

It is quite explicit in the standard. Allowing it for non-integers is an
extension that I've seen before. If you want to do that in an (almost)
standard-conforming way, use equivalence or transfer to copy the bits
from the real into an integer.

The "almost" qualifier is because the resulting integer is technically
undefined in the equivalence case, and processor-dependent in the
transfer case. So strictly speaking, nothing is guaranteed, but even teh
compilers that try to track undefined status won't catch that one in
practice.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain