Re: [Gm2] Re: FIO EOF fixed

[SiTex Graphics]

Hi Gaius,

I think I've found the problem:  FIO.IsNoError() treats the new EOF
state as an error:

RETURN (fd#NIL) AND (fd^.state=successful)

That is bad because according to the man page, the linux fread command
simply returns 0 at the end of file and does not set the stream state
to an error or set errno.  When FIO.IsNoError returns FALSE at EOF,
RTgen.checkErrno checks the errno which will be whatever was set by
the last system call that failed.  That explains the erratic behavior
I was seeing, where some files loaded fine but others did not.

My quick fix is to modify IsNoError() so EOF is no longer an error:

RETURN (fd#NIL) AND ((fd^.state=successful) OR (fd^.state=endoffile));

which seems to work for our apps at least.  I'm not sure how that
might affect other parts of the file IO routines.

Regards,
Scott



On Thu, May 6, 2010 at 11:24 PM, SiTex Graphics <address@hidden> wrote:
> Hi Gaius,
>
> The behavior I reported for wraptime did indeed seem weird.  I checked
> to see whether the new .o files were properly installed and discovered
> that the installed .o files were from January.  I thought 'make
> install' would automatically overwrite those (as it does for gm2 etc),
> but apparently it does not.
>
> After removing the old .o files and re-running make install, wraptime
> now behaves as expected.
>
> But IOChan.RawRead now generates an unexpected exception in our main
> application.  It only happens with some files, and so far I haven't
> been able to reproduce the error in a standalone test.  Attempting to
> track down the exception source I tried the following after EXCEPT in
> my wrapper procedure for RawRead:
>
> 1. EXCEPTION.GetMessage() doesn't return anything (and maybe even
> generates a new exception?)
>
> 2. IOChan.IsChanException() returns FALSE
>
> 3. IOChan.DeviceError() returns 2
>
> -Scott
>
>
> On Thu, May 6, 2010 at 7:35 AM, Gaius Mulley <address@hidden> wrote:
>> SiTex Graphics <address@hidden> writes:
>>
>>> Hi Gaius,
>>>
>>> I'm going to cautiously say that the EOF code is working.  I still
>>> have the problem with short reads unless I use my own "vanilla"
>>> compile of RTgen.  The RTgen.o produced by the make process returns a
>>> short read when the 16k buffer gets full and the file length is
>>> greater than 16k but less than 32k.  I can put together a test case if
>>> that would help.
>>
>> Hi Scott,
>>
>> yes please - the more test code the better.  I'm going to write some
>> test code which reads exactly 16k and pushes a char back and then
>> reads until eof and pushes a char back.
>>
>>> Also, although wraptime.c has the fix for seconds, I only get reliable
>>> results for seconds by using a simple compile of wraptime.c instead of
>>> the .o produced by the make process.
>>
>> weird - could you possibly capture the C preprocessor output of
>> wraptime.c - you can do this by:
>>
>>
>> $ cd build-4.1.2/gcc
>> $ rm gm2/gm2-libs-iso/wraptime.o
>> $ make gm2/gm2-libs-iso/wraptime.o
>>
>>  <...  lots of gcc command line info ...>
>>
>> now cut and paste this command line and repeat it but critically
>> modify it by
>>
>> replacing  '-c' by '-E'
>>
>> and altering the destination output to say
>>  -o cppwraptime.build
>>
>> if you can do the same for you private working compile of wraptime,
>> say use:
>>  -o cppwraptime.local
>>
>> and email me these two files - hopefully I'll see enough differences.
>> Probably a configure issue..
>>
>> regards,
>> Gaius
>>
>