[comp.lang.fortran] "arithmetic if":: Re: Feature for the next C version

mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel) (07/30/89)

This article has been crossposted to comp.lang.c (the original
newsgroup) and comp.lang.fortran.  Please send all followups to
comp.lang.fortran.

In article <8515@batcomputer.tn.cornell.edu>
davidra@tcgould.tn.cornell.edu (David Rabson) writes:
>200   FORMAT(I)

In article <3600@csd4.milw.wisc.edu> zdenko@csd4.milw.wisc.edu (Zdenko
Tomasic) writes:
> This reserves integer field of only one digit/sign.

FORTRAN 77, and presumably FORTRAN 66, do not allow the I format
descriptor to appear without a width.  On Alliant computers, an I
without a width is permitted as an extension, and the width is assumed
to be 7 characters for one- and two-byte integers, and 12 for 4-byte
integers.

> when you use signed integer, sign is taken, but the magnitude (2nd
> character and beyond!) is not read!  So you program get by fortran
> conversion -0 which is equivalent to 0.

What if you're on a one's complement machine?  On those, -0 need not
be the same as 0.

VAX BSD 4.3, SUN OS 3.5, and Alliant Concentrix 3.0 all treat a single
"-" in an otherwise blank field as 0.  However, I have found no
statement in my manuals guaranteeing it, and if I were writing a
FORMAT conversion library, I'd consider making it illegal as an
ill-formed number.  (After all, these
        I = -           ! FORTRAN
        i = -;          /* C, C++ */
are not legal -- why not be consistent, if the standard permits it?)

> You either have to increase your integer field length (say I10)
Yes.

> and right justify your input (trailing blanks within an integer
> field are treated as zeros!) 

In FORTRAN 77, you can use the BLANK= attribute on the OPEN statement
to control whether trailing blanks are ignored or treated as zeroes,
by
        BLANK='NULL'
or      BLANK='ZERO'
The default is NULL -- by default trailing blanks are simply ignored.
I don't believe FORTRAN 66 took a stand on the issue, and in its
default, implementors treated trailing blanks as zeroes.

Briefly, trailing blanks *may be* treated as zeroes.

> much more conveninetly, use list directed read, i.e. replace the
> read and format statement above with just READ(5,*) I

Quite true!  It is much better for interactive input.

--
"Let me control a planet's oxygen supply, and I don't care who makes
the laws." - GREAT CTHUHLU'S STARRY WISDOM BAND (via Roger Leroux)
 __
   \         Tim, the Bizarre and Oddly-Dressed Enchanter
    \               mcdaniel@uicsrd.csrd.uiuc.edu
    /\       mcdaniel%uicsrd@{uxc.cso.uiuc.edu,uiuc.csnet}
  _/  \_     {uunet,convex,pur-ee}!uiucuxc!uicsrd!mcdaniel

zdenko@csd4.milw.wisc.edu (Zdenko Tomasic) (07/30/89)

In article <1614@garcon.cso.uiuc.edu> mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel) writes:
>...
>In FORTRAN 77, you can use the BLANK= attribute on the OPEN statement
>to control whether trailing blanks are ignored or treated as zeroes,
>by
>        BLANK='NULL'
>or      BLANK='ZERO'
>The default is NULL -- by default trailing blanks are simply ignored.
>I don't believe FORTRAN 66 took a stand on the issue, and in its
>default, implementors treated trailing blanks as zeroes.
>
>Briefly, trailing blanks *may be* treated as zeroes.
>

FORTRAN66 required that all trailing blanks be treated as zeros
(see 7.2.3.6 of FORTRAN66, page 20). It is interesting that
FORTRAN77 chose to make a different default. I wonder how many
people have bad experiences porting dusty input decks because of that.
Better yet how many people are aware of either default?
--
___________________________________________________________________
Zdenko Tomasic, UWM, Chem. Dept., P.O. Box 413, Milwaukee, WI 53201
UUCP: uwvax!uwmcsd1!uwmcsd4!zdenko
ARPA: zdenko@csd4.milw.wisc.edu