Re: bug in g95 ?
From: E P Chandler (epc8_at_juno.com)
Date: 11/30/04
- Next message: glen herrmannsfeldt: "Re: g95 wish list"
- Previous message: David Ham: "Re: g95 wish list"
- In reply to: Jean-Baptiste FAURE: "bug in g95 ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 30 Nov 2004 02:36:36 -0800
Jean-Baptiste FAURE <faure@lyon.cemagref.fr> wrote in message news:<41AC200B.9080007@lyon.cemagref.fr>...
> Hello,
>
> I guess there is a bug in len_trim() implementation in g95
> try these program :
>
> program test
> implicit none
> character*35 :: client
> open(unit=1,file='test.dat',form='formatted',status='old')
> read(1,'(a)') client
> write(*,*) len_trim(client)
> client = 'a character string'
> write(*,*) len_trim(client)
> stop
> end
> where test.dat contains the string :
> a character string
>
> When I compile test with g95 under w2k the results are 19 and 18.
> If you add blanks at the and of the line in the file, test counts these
> blank characters.
> With CVF 6.1a and ftn95 I get 18 and 18.
>
> JBF
With g95 it depends on the end of line markers in 'test.dat' (under
WinXP). A <lf> delimited text file gives correct results, but a
<cr/lf> delimited text file exhibits the 'bug'. While many *nix
programs ported to dos/windows translate <cr/lf> to <lf> on text input
and <lf> to <cr/lf> on text output, g95 does not do that here. Instead
<cr> is counted as a non white space character, hence trailing blanks
are also counted.
note:
C:\g95>g95 --version
G95 (GCC 3.5.0 20040824 (experimental) (g95!) Nov 12 2004)
[snip]
- Next message: glen herrmannsfeldt: "Re: g95 wish list"
- Previous message: David Ham: "Re: g95 wish list"
- In reply to: Jean-Baptiste FAURE: "bug in g95 ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|