Re: [gccsdk] gcc Digest, Vol 89, Issue 4

On 06/03/14 20:00, gcc-request@gccsdk.riscos.info wrote:
> [snipped]
>
> On 04/03/14 11:05, david_m_gee wrote:
>> On GCC 4.1.2/Unixlib, running on a Raspberry Pi, fgets() does not appear
>> to work. It returns NULL when there is data in the file to read. It
>> makes no difference whether the code is statically or dynamically
>> linked, but the shared C library version works fine with exactly the
>> same data file.
>>
>> See https://www.riscosopen.org/forum/forums/11/topics/2447 for further
>> details.
> I tried the test binaries, both dynamic and static, with RISC OS running
> in rpcemu. They both worked as expected. When you say that there is an
> infinite loop, do you get:
>
> 0 :
>
> repeated over and over? I found that this occurred when the test file
> was not found. For example, from the directory holding the binary and
> test file:
>
> testdynamic errors/lst
>
> failed with an infinite loop as above, but
>
> testdynamic errors.lst
>
> worked correctly.
> This may explain why it works with the SharedCLibrary as it doesn't
> use filename translation.
>
> Perhaps you could alter the code to test the result of fopen to ensure
> the file is in fact being found?
>
> Thanks,
> Lee.
>
>
>
Yes, that's it exactly. I forgot that Unixlib would expect Unix-style
file specifications. Normally I would check that the file existed but in
this particular case, the program isn't called unless the file _is_
there (there's an IfThere command in an obey file).

Obviously if I wanted to I could then use __unixify_std (or similar)
from unixlib/local.h but in this case compiling to use the Shared C
Library seems better--it works correctly without needing an additional
function call and the binary produced is also smaller.

--
David Gee


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK