PR23154 Re: CREAD buggy? Can't reproduce the problem

[Jerry DeLisle]

Jack Howarth wrote:
> Jerry,
>     Good news, bad news. The good news is I found a hack that works around
> this problem. The code in xplor-nih resembles the following test case...
> 
>       PROGRAM BUG
>       CHARACTER*(132) COMLYN
>       COMMON /COMMAND/COMLYN
>       DOUBLE PRECISION XIN, YIN, ZIN, WIN, QIN
>       CHARACTER*4 SID, RID, RID2, REN, IUP
>       CHARACTER*5 A       
>       COMLYN='ATOM      1  C4  DNP   250      -4.070  58.954 181.339  1.00  0.00
> '   
>       WRITE(6,*) COMLYN
>       READ(COMLYN,'(12X,A4,1X,A4,1X,A5,3X,3F8.3,F6.2,F6.2,6X,A4)',
>      &           ERR=8888) IUP,REN,A,XIN,YIN,ZIN,QIN,WIN,SID
>       GOTO 9999
> 8888  WRITE(6,*) ' read failed'
>       CALL ABORT()
> 9999  WRITE(6,*) ' read passed'      
>       WRITE(6,'(12X,A4,1X,A4,1X,A5,3X,3F8.3,F6.2,F6.2,6X,A4)') IUP,REN,A,XIN,YIN
> ,ZIN,QIN,WIN,SID
>       END
> 
I can not reproduce the problem here.  The test case I had was bogus because I 
was exceeding the column 72 for fixed-form, and so part of the string was 
missing.  Setting the continuation correctly or using -ffixed-line-length-132 
allows your test case and my test case to work fine.

At this point I would suspect that something else is hammering memory.  A loose 
pointer maybe.  I don't think its the I/O routines.  Let's keep the pr open to 
track further on this.  Someone is going to have to get the source and run 
valgrind as Steve suggested.  I have valgrind, but do not have the source yet.

-- Jerry