Thursday, 6 March 2014

Re: [gccsdk] fgets problem/Unixlib

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.


_______________________________________________
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

No comments:

Post a Comment