Re: [Gm2] Re: FIO EOF fixed

[Gaius Mulley]

SiTex Graphics <address@hidden> writes:

> 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.

Hi Scott,

thanks for the analysis - yes it does appear so.  I've made the change
below and I've had to modify a few other procedures inside FIO which
assumed IsNoError included (not eof).  Also had to change a few pim
library implementations - I'm in the process of rebuilding gm2 and
running all regression tests.  Once all the regressions pass I'll
commit the changes,

regards,
Gaius


>
> 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
>>>
>>