IOSTAT error or improper interpretation

[Xj_Kong]

character*100::str

real*8::num

str=11-30

read(str,*,iostat=ior)num

!------------ after run :----------------------
! no error report can be found since ior is 0 and num is interpreted as 11.0E-30 which seems weird.

[John4]

I suppose you meant

str='11-30'

In the code.

In Fortran's terms, str is as an internal file, so the +,-,* and / characters have special meanings whenever they come from a file.

In such case, + and - are for exponents ---i.e., "1+3" and "2-5" are treated the same as 1.0E+003 and 2.0E-5, respectively.

You can check "Rules for Input Processing" in the "F editing" section in the compiler's documentation for further details.

[Xj_Kong]

Sorry I avoided to open external file and used internal file as str='11-30'.

However, I can not see there is any difference regarding IOSTAT for internal and external files.

Anothing example

character*100::str='10-20 73*50 '
real*8::num1,num2,num3

read(str,*,iostat=ior)num1,num2,num3

! ior still equal to zero and num1=1D-19, num2=50, num3=50

Yes, thank you very much. 

[Steven_L_Intel1]

The external/internal attribute is not relevant. As John correctly says, the string "11-30" is being treated as if it were 11.0E-30. You should not be relying on list-directed input giving an error for doing input validation, as it tends to accept many strings you might think invalid.

The reason "11-30" is accepted is that in an E or D format output, when the exponent has three digits, the exponent letter is omitted. But in such cases the decimal point is still required and I'm not really happy about it accepting this string which would never be output, I will ask the developers if they'll make this an error. Issue ID is DPD200255204.

[Steven_L_Intel1]

I should have stared at the standard a bit more. The standard requires that "11-30" be accepted as if it were 11.E-30. Here's the words in the standard:

The input field is either an IEEE exceptional specification or consists of an optional sign, followed by a string of
one or more digits optionally containing a decimal symbol, including any blanks interpreted as zeros. The d has
no effect on input if the input field contains a decimal symbol. If the decimal symbol is omitted, the rightmost
d digits of the string, with leading zeros assumed if necessary, are interpreted as the fractional part of the value
represented. The string of digits may contain more digits than a processor uses to approximate the value. The
basic form may be followed by an exponent of one of the following forms:
• a sign followed by a digit-string;
• the letter E followed by zero or more blanks, followed by a signed-digit-string;
• the letter D followed by zero or more blanks, followed by a signed-digit-string.

So in this case, the "basic form" is the 11, and the exponent is the -30 (sign followed by a digit string). Legal according to the standard. Not a bug.

[Stephen_Sutcliffe1]

A question on a related topic

Is it possible to write exponential E and D formats with the "E"/"D" omitted using a standard fortran format statement. MSC NASTRAN software uses this format in it's input decks as there is an option to use a limit of 8 characters per field for all data items. This format makes the files more readable but can result in rounding errors if you are not careful. I have written my own routine for doing this but I'd rather use an intrinsic format if possible as it would perform the operation quicker and cleaner. In other words is there a format descriptor that would write a real number to an <n> character field to represent the value as accurately as possible?

[Steven_L_Intel1]

Stephen, no, there isn't. If you use the D or E format without the Ee modifier (that specifies the number of exponent digits), and the exponent would have three digits, the letter is removed, but that's the only circumstance where that happens.