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
|
