Prev: use module to pass data between procedures
Next: It Hurts When I Do This -- diversion...
From: SimonG on 22 Apr 2008 04:53
I have built the following program with both ifort (Intel) and g95 but
they yield different results:

program ex
implicit none
real(8) :: x
integer :: n
character(10) :: buff

do
write(6,'(a)',advance='no') '> '
read(5,*) buff
read(buff,*,err=900) x
write(6,'(2a)') 'Number:',trim(buff)
cycle
900 continue
write(6,'(2a)') 'Command:',trim(buff)

end do

end program ex

On the Intel version entering '+' results in 'Command:+' whereas with
the g95 version the result is 'Number:+'. I expected the Intel result
but perhaps the standard is ambiguous on this. Is this a g95 bug?

A second question: how do I enter a '/' character?

Thanks,

Simon Geard
From: Arjen Markus on 22 Apr 2008 05:06
On 22 apr, 10:53, SimonG <si...(a)whiteowl.co.uk> wrote:
> I have built the following program with both ifort (Intel) and g95 but
> they yield different results:
>
> program ex
>   implicit none
>   real(8) :: x
>   integer :: n
>   character(10) :: buff
>
>   do
>      write(6,'(a)',advance='no') '> '
>      read(5,*) buff
>      read(buff,*,err=900) x
>      write(6,'(2a)') 'Number:',trim(buff)
>      cycle
> 900  continue
>      write(6,'(2a)') 'Command:',trim(buff)
>
>   end do
>
> end program ex
>
> On the Intel version entering '+' results in 'Command:+' whereas with
> the g95 version the result is 'Number:+'. I expected the Intel result
> but perhaps the standard is ambiguous on this. Is this a g95 bug?
>
> A second question: how do I enter a '/' character?
>
> Thanks,
>
> Simon Geard

With list-directed input a bare / ends the input, as you know. Put it
in '' or "" and it should work.

I do not know the answer to your other question though, but such edge
cases might indeed be ambiguously (or not at all) treated in the
standard.

Regards,

Arjen
From: fj on 22 Apr 2008 05:07
On 22 avr, 10:53, SimonG <si...(a)whiteowl.co.uk> wrote:
> I have built the following program with both ifort (Intel) and g95 but
> they yield different results:
>
> program ex
> implicit none
> real(8) :: x
> integer :: n
> character(10) :: buff
>
> do
> write(6,'(a)',advance='no') '> '
> read(5,*) buff
> read(buff,*,err=900) x
> write(6,'(2a)') 'Number:',trim(buff)
> cycle
> 900 continue
> write(6,'(2a)') 'Command:',trim(buff)
>
> end do
>
> end program ex
>
> On the Intel version entering '+' results in 'Command:+' whereas with
> the g95 version the result is 'Number:+'. I expected the Intel result
> but perhaps the standard is ambiguous on this. Is this a g95 bug?
>
> A second question: how do I enter a '/' character?
>
> Thanks,
>
> Simon Geard

For the second question, use '(a)' instead of * when reading buff

For the first one, I think that g95 should report an error, "+" alone
being not a number.
From: FX on 22 Apr 2008 05:12
> 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
bugreport 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 shift 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

From: SimonG on 22 Apr 2008 06:09
On Apr 22, 10:12 am, "FX" <coud...(a)alussinan.org> 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
> bugreport 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 shift 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
 |  Next  |  Last
Pages: 1 2
Prev: use module to pass data between procedures
Next: It Hurts When I Do This -- diversion...