[gccsdk] fgets problem/Unixlib

John Tytgat John.Tytgat at aaug.net
Sat Mar 8 07:34:37 PST 2014


In message <53185D39.9090501 at sky.com>
          Lee Noar <leenoar at sky.com> wrote:

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

Normally EOPSYS is only returned as last resort.  There is a lot of effort
done to try to map RISC OS errors into proper errno error values but of
course this assumes e.g. that filing systems do return their error numbers
according to PRM 2-258.

Roughly a year ago I did several UnixLib fixes for returning more
accurate errno error values and made a small unittest framework
(recipe/files/gcc/libunixlib/unittest) for testing these changes.  It
would be interesting to have those unittests run on HostFS instead of
a FileCore based FS what I used at that time.  My guess is that HostFS
will fail more of those unittests...

Aside, while writing this mail, I noticed that our mkdir() implementation
could do a better RISC OS error number check, I've fixed that with r6620.

John.
-- 
John Tytgat, in his comfy chair at home
John.Tytgat at aaug.net




More information about the gcc mailing list