riscosify and /home/riscos/env/

Theo Markettos theo at markettos.org.uk
Wed Jun 15 07:13:43 PDT 2005

On Wed, Jun 15, 2005 at 01:07:17AM +0200, John Tytgat wrote:
> Did you also made changes so that __unixify() on foo:bar results in
> /home/riscos/env/foo/bar (i.e. the reverse translation) ?

No, is this necessary?  Under this scheme there's not a 1:1 mapping between
riscosify and unixify because if asked to unixify a path mem:foo how do I
know whether mem: is a RISC OS path variable or a filing system?  At the
moment this gets unixified into /mem:foo/  IMO it would be a bit surprising
to have this translated to /home/riscos/env/mem/foo/ if you didn't ask for

There are two issues here.  Firstly it is this unixified value is what will
be used when the program prints something under RISC OS.  Having
/home/riscos/.../ might confuse the user somewhat.  Secondly this path is
what will be used in the cross compile process if you want to do
--prefix=myapp: but Makefiles etc will cause trouble due to the colon.

I suppose we could say that /mem:foo/ was fairly useless as a Unix
path and we ought to make it something that has a chance of working when
cross compiling.  But I don't think this is that necessary, and to usurp the
default mapping of "/mem:"=unixify("mem:") would break the principle of
least surprise.
> I don't think it will be an issue for your patch but have a look at
> the source/unix/dirent.c if those routines keep on working with e.g.
> /home/riscos/env/foo/bar as opendir() argument (assuming bar is a dir).

I can't see a problem looking at the code, and the regression test (thanks
Alex for pointing them out!) tst-seekdir works as expected.  In this case
it's just another way of representing /foo:bar/ that we had before and
there's nothing that uses the unix name before it gets riscosified.


More information about the gcc mailing list