On Apr 22, 1:42 pm, Dick Hendrickson <dick.hendrick...@[EMAIL PROTECTED]
> wrote:
> SimonG wrote:
> > On Apr 22, 10:12 am, "FX" <coud...@[EMAIL PROTECTED]
> wrote:
> >>> I expected the Intel result but perhaps the standard is ambiguous on
> >>> this. Is this a g95 bug?
> >> I'd have the same expectation that you have, so I guess there's a
> >> bugre****t to make (or at least feature request, as lots of other
> >> compilers behave the other way).
>
> >>> A second question: how do I enter a '/' character?
> >> Well, you have a .co.uk address, so the '/' key should be on the left
of
> >> your right ****ft key ;-)
>
> >> Hum, more seriously, you need to change your read's into:
>
> >> read(5,'(a)') buff
> >> read(buff,'(f20.0)',err=900) x
>
> >> (Oh, and doing that fixes the issue with g95, apparently.)
>
> >> --
> >> FX
>
> > Yes, making that change does alter the behaviour - the g95 version
> > works as required but the Intel version now interprets '+' as a number
> > (as well as '.', ',' and '-'): is that an Intel bug?
>
> > In fact for read(buff,'(f10.0)',err=900) x
>
> > input g95 ifort
> > + Command:+ Number: 0.
> > - Command:- Number: 0.
> > * Command:* Command:*
> > / Command:/ Command:/
> > . Command:. Number: 0.
> > , Command:, Number: 0.
>
> > and for read(buff,*,err=900) x
>
> > input g95 ifort
> > + Number: 0. Command:+
> > - Number: -0. Command:-
> > * Command:* Command:*
> > / Number: -0. Number: 0.
> > . Number: 0. Command:.
> > , Number: 0. Number: 0.
>
> > program ex
> > implicit none
> > real(8) :: x
> > integer :: n, ios
> > character(10) :: buff
>
> > do
> > write(6,'(a)',advance='no') '> '
> > read(5,'(a10)') buff
> > read(buff,*,err=900) x !!! or read(buff,*,err=900) x
> > write(6,'(a,f10.0)') 'Number:',x
> > cycle
> > 900 continue
> > write(6,'(2a)') 'Command:',trim(buff)
>
> > end do
>
> > end program ex
>
> > So what is the correct behaviour, surely they can't both be right.
>
> > Simon Geard
>
> I believe a plus or minus sign that is not followed by some
> digits is an error.
>
> 10.6.1.2.1 F editing says
> "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."
>
> 10.9.1 List directed input says
> "Input forms acceptable to edit descriptors for a given type are
> acceptable for list-directed formatting...."
>
> You need a digit after the sign for it to be suitable for either
> F or * input.
>
> Unfortunately, the standard is pretty weak on specifying what is
> an error. There is no list of conditions that require the ERR=
> branch to be taken. In fact, 9.10 Error, end-of-record, and
> end-of-file conditions says
> "The set of input/output error conditions is processor dependent."
>
> It's arguably standard conforming for a processor to not re****t an
> error and instead do [what it thinks is] the right thing.
>
> Think about using the INDEX intrinsic to check for digits in buff,
> or compare something like ADJUSTL(TRIM(BUFF)) with "+" rather
> than relying on the read statement to detect the right kind of
> thing.
>
> Dick Hendrickson
I was hoping I would be able to avoid parsing the string myself but it
seems not. The following gives the required behaviour:
program ex
implicit none
real(8) :: x
integer :: n
character(10) :: buff
integer :: blen
character(6) :: commands = '+-*/.,'
do
write(6,'(a)',advance='no') '> '
read(5,'(a10)') buff
buff = trim(adjustl(buff))
blen = len_trim(buff)
if (blen == 1 .and. scan(buff(1:1),commands) /= 0) then
goto 900
end if
read(buff,*,err=900) x
write(6,'(a,f10.0)') 'Number:',x
cycle
900 continue
write(6,'(2a)') 'Command:',trim(buff)
end do
end program ex
Thanks,
Simon Geard
|
