John Tytgat John.Tytgat at aaug.net
Wed Jan 12 16:02:43 PST 2005

In message <6c3c482b4d.ajw498 at caramel.cp15.org>
          Alex Waugh <alex at alexwaugh.com> wrote:

> In message <a363452b4d.Jo at hobbes.bass-software.com>
>           John Tytgat <John.Tytgat at aaug.net> wrote:
> > In message <9cf93e2b4d.ajw498 at caramel.cp15.org>
> >           Alex Waugh <alex at alexwaugh.com> wrote:
> > [...]
> [...]
> The current behaviour of riscosify is to convert any RISC OS or unix
> filename if it is unambiguous, but if there is some ambiguity then the
> guess_or_null function gets called. It is only in guess_or_null that
> __RISCOSIFY_STRICT_UNIX_SPECS is checked. The only two cases when
> guess_or_null gets called, and hence __RISCOSIFY_STRICT_UNIX_SPECS has
> any effect, is for relative filenames and filenames starting with a path
> variable.

I didn't realise this was currently the case.

> > Now back to the RISC OS path variable part when
> > __RISCOSIFY_STRICT_UNIX_SPECS is set.  To be honest, I feel this is a
> > little bit against the original idea of this bit definition.  I'm wondering
> > if you don't want to have it unset for your purpose.  Could you elaborate
> > this more please ?
> This was for my Subversion port, where the code is always dealing with
> unix filenames,

Uh, then I guess you're dealing with the same issues as in my CVS port.
Support you checkout a file from a remote repository having a ':' in its
(Unix) name. What happens ? My experience is that if you don't have a
bijective mapping from Unix specs to RISC OS specs and back, that you have
hairy issues.  The more RISC OS features (like paths) you're allowing in
your Unix specs (and still with their RISC OS semantics), the more hairy
the situation gets.

> however it was being linked to an ssh library which
> had filenames such as Choices:Crypto.PuTTY.sshknownhosts
> hardcoded. It would be trivial to change these hardcoded filenames, but
> I was expecting riscosify to be able to cope with them.

I'm not sure I'm sharing the same expectation.  This makes me thinking
and I see the following problem when we're going to move to using more
sharable modules : each module might have its own preference or even
requirement for its filepath translations.  This could mean we have to go
for one __riscosify_control value for all sharable modules.  Thoughts ?

John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven

More information about the gcc mailing list