[gccsdk] fgets problem/Unixlib

Lee Noar leenoar at sky.com
Thu Mar 6 03:34:17 PST 2014


On 05/03/14 21:41, Theo Markettos wrote:
> On Wed, Mar 05, 2014 at 08:06:57PM +0000, Lee Noar wrote:
>> 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:
>
> As a warning, UnixLib's behaviour is quite sensitive to the underlying filing
> system.
>
> I have a port of git, which doesn't work due to filename issues.  It turns
> out it has completely different filename issues on RAMFS and HostFS on
> rpcemu (0.8.9 Mac, RO5.21 of recent vintage).  I haven't followed everything
> through to work out the full details, but the final error (from git-add)
> that happens on HostFS is it tries to open() a file in a nonexistent
> directory.  git's code will look for ENOENT, backtrack, create the directory
> and try again.  On RAMFS this works OK (the code later falls over
> elsewhere).  On HostFS open() returns EOPSYS, the git error checking code
> doesn't know what to do with this, and so falls over.  HostFS is returning a
> different error from FileCore, UnixLib isn't matching on that, and so it
> returns a UnixLib-specific errno.
>
> So always worth testing on a range of filing systems, because behaviours can
> differ.

EOPSYS is a RISC OS specific code for an operating system error which of
course is not recognised by ported software. I think to avoid problems
like you are having, open() should not be returning EOPSYS - it should
only return one of the errors defined in the spec:

<http://linux.die.net/man/3/open>

I'll see if I can substitute more suitable codes.

Thanks,
Lee.





More information about the gcc mailing list