Hi all,
it is interesting to watch the discussion, thanks.
The purpose of my request (copied below) was to become able to produce a
more user-friendly software product: the program should just not
terminate if "just" a letter (i.e., instead of a number) was wrongly
typed in for a real or integer variable input, the user would be given
ntry chances, with ntry in the order of 5.
However, the software should detect if something has been wrongly typed in.
I am surprised that at least one compiler (Absoft) has problems with
that. I checked the code (below) with gfortran-compilation:
q (ioerr .ne. 0)
e (ioerr .ne. 0)
/ (a unchanged)
i (proceeded one line, upon seemingly any next input iorr .ne. 0)
d (ioerr .ne. 0)
n (proceeded one line, upon seemingly any next input iorr .ne. 0)
gfortran seemed in this respect to behave better (more "ioerr .ne. 0")
than Absoft.
I am too lazy to complain to the compilor makers, but some of them
perhaps subscribe to our newsgroup!?
Best
Manfred
Am 10.02.2011 07:29, schrieb Malcolm Cohen:
>> A program is a standard-conforming program if it uses only those
>> forms and relationships described herein and if the program has
>> an interpretation according to this part of ISO/IEC 1539.
>>
>> So,
>>
>> READ(*,*) A
>> WRITE(*,*) A
>> END
>>
>> we usually say this program is standard-conforming.
>
> Yes, and it is given valid input data.
>
>> But if we
>> depend on this program to, say, abort with an error message for a
>> non-numeric input value, this program is not standard-conforming??
>
> Correct. The standard does not give the program an interpretation when
> it is applied to invalid data.
>
> If the input data is the record
> FRED
> then it does not satisfy the standard which says (page 263, 10.10.3
> paragraph 1 sentence 2):
> "The form of the input value shall be acceptable for the type of the
> next effective item in the list."
>
> "shall" is a requirement. "FRED" is not an acceptable form for REAL A.
> End of story.
>
> One can write programs that don't violate the standard for invalid
> input, by having the program do input validation itself (i.e. by reading
> it into a CHARACTER variable and checking the format). Admittedly that
> is pretty tedious so people rarely bother, either because they "know"
> that their input is valid, or because they trust the compiler to
> generate a nice error code for them. And most compilers do... but in
> fact it is not required.
>
> Cheers,
original request:
===
Dear all,
I was puzzled by the behaviour of the Fortran 90 code below (compiled
with AbSoft 10.0, Windows XP machines, keyboard language German): the
executable took without complaining (i.e., ioerr = 0) following inputs
of mine at the read statement for the real variable and reset the a
values (in parentheses as follows:
q (a = 0)
e (a = 0)
/ (a unchanged)
i (a = INF)
d (a = 0)
n (a = NaN)
(Putting in ordinary stuff like numbers worked (ioerr .ne. 0) of course,
while putting in other unordinary stuff like $ worked not.
I have the feeling that all this is not a compilor error but a well
known Fortran behaviour since the 1960s, some old-fashioned convention.
Anyway, I would highly appreciate if someone could enlighten me in that
respect. Many thanks!
Manfred
===
program test
integer :: i
integer :: ioerr
real :: a = -999.0
print *, a
do i=1,100
print *, 'Input new value: '
read (unit=5, fmt=*, iostat=ioerr) a
print *, ' ioerr = ',ioerr,' a = ',a
end do
end program test
===
--
Dr. Manfred Mudelsee
Chief Executive Officer
Climate Risk Analysis - Manfred Mudelsee e. K. (HRA 20 13 94)
Schneiderberg 26
30167 Hannover
Germany
Telephone: +49 (0)511 7003 2891
Fax: +49 (0)511 7003 2892
Email: [log in to unmask]
URL: http://www.mudelsee.com
Research Scientist
Alfred Wegener Institute for Polar and Marine Research
Climate Science Division
Bussestrasse 24
27570 Bremerhaven
Germany
|
