J3/02-320r2 Date: Nov 13, 2002 To: J3 From: Dick Hendrickson Subject: Response to Public Comment 9 from Arjen Markus > From: Arjen Markus > Sent: Thursday, October 31, 2002 4:38 AM > To: Donovan, Deborah > Subject: Comments w.r.t. Fortran 2000 > > Dear madam, > > I approach you directly, instead of via my national standards body, > because I could not find the proper address. > > I would like to send you the following comments on the draft Fortran > 2000 > standard. They may be small details, but I would appreciate it if you > could pass them on. > > My main source of information is the latest issue of the Fortran Forum, > which describes this standard. > > The intrinsic module ISO_FORTRAN_ENV should in my opinion contain > as much of the environment as possible, certainly those items that > may be of influence on the working of the Fortran program. I think > the following are missing: > > 1. Indication of big-endian or little-endian format for the > representation of numbers. > If this information is known at run-time certain operations, > like reading binary files from other sources can be made essentially > platform-independent. > NO, we feel this is too system dependent to be standardized. Many processors provide for dealing with this as a command line or OPEN option. Fortran has resisted standardizing details of implementation at this level. > 2. Unit used for the record length of direct-access files. > Right now this is a piece of information that influences the results > enormously and is difficult (though not impossible) to assess at > run-time. > YES, we will recommend that constants be added that specify the size in bits of the file storage unit, a numeric storage unit, and a character storage unit. > 3. Some indication of the file system when one has to construct proper > file names, for instance, the character used to separate directory > names. NO, it is difficult to standardize since some systems do not have a directory concept, nor is it guaranteed that if they do, the separator will be a single character. > > 4. The maximum length of messages from the IOMSG= keyword. > That way, one can simply declare a string like: > > CHARACTER(LEN=MAX_MSG_LENGTH) :: string > > and be sure that the message is saved in its entirety > NO, this isn't possible since some IO Messages are composed by the processor on the fly, perhaps containing the format, the line in error, or the file name. Also, user defined IO routines can return an IOMSG string of arbitrary length. > Other comments: > 5. Does FLUSH allow the flushing of the standard output > (FLUSH(OUTPUT_UNIT) > would work as I expect?) Any unit may be specified for the FLUSH statement. The results are system dependent, but means are provided to detect "inappropriate" but "harmless" use of a FLUSH. > > 6. Is there a way to influence the rounding mode for calculations (it is > possible for formatted output) Yes, the IEEE modules provide for run-time control of rounding. See section 14.3 > > 7. The current way of interfacing C and Fortran (via essentially > FORTRAN77 > constructs and platform-dependent encoding in C) will still work? > This is outside the scope of the standard; but we do not believe we have done anything that would preclude existing practice in this area. The new C interoperability features should remove (most of) the need for system dependent coding. > Kind regards, > > Arjen Markus