I've come across a very rare situation where a Win32 process is outputting to a console output and using 'cr' without being followed with a 'lf' character ( Ascii 13 NOT followed by Ascii 10 ) for a newline. The current ReadLine in pub.mod/freeprocess.mod/freeprocess.bmx doesn't account for this and either bugs out with an 'array out of range' or an EAV.
Here is a proposed fix to account for this situation.
Method ReadLine$() 'nonblocking - returns empty string if no data available
Local n,r,p0,p1,line$
n=ReadAvail()
If n
If bufferpos+n>4096 n=4096-bufferpos
If n<=0 RuntimeError "PipeStream ReadBuffer Overflow"
r=Read(Varptr readbuffer[bufferpos],n)
bufferpos:+r
EndIf
For n=0 To bufferpos
If readbuffer[n]=10 Or (readbuffer[n] = 13 And readbuffer[n+1] <> 10) ' changed
p1=n
If (n>0)
If readbuffer[n-1]=13 p1=n-1
EndIf
p0=0
If readbuffer[0]=13 p0=1
If p1>p0 line$=String.FromBytes(Varptr readbuffer[p0],p1-p0)
n:+1
bufferpos:-n
If readbuffer[n-1] = 13 And readbuffer[n] <> 10 ' added so as to not change the main algo and to account for a possible cr without lf combination.
If bufferpos = -1 bufferpos = 0
EndIf
If bufferpos MemMove(readbuffer,Varptr readbuffer[n],bufferpos)
Return line$
EndIf
Next
End Method
|