[gccsdk] gcc Digest, Vol 89, Issue 4

David Gee david_m_gee at blueyonder.co.uk
Sun Mar 9 04:56:05 PDT 2014


On 06/03/14 20:00, gcc-request at 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





More information about the gcc mailing list