__RISCOSIFY_STRICT_UNIX_SPECS

Alex Waugh alex at alexwaugh.com
Mon Jan 10 14:52:41 PST 2005


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 __RISCOSIFY_STRICT_UNIX_SPECS option to riscosify is useful when
> > dealing with ambiguous relative filenames,
> 
> I'm not sure about that.  It is simply restricting the detection and support
> of RISC OS specific file spec aspects in the Unix file specs.  I.e. when set,
> you want to have as strict Unix file specs as possible.  I.e. the directory
> separator is a slash and nothing else.  Characters like :, ^, $, etc do
> not mean anything special.  At one point I even had code which translated
> those special RISC OS file characters into an escaped notation which gets
> reversed in the unixify() routine (as better solution for the current
> __filename_char_map remapping), but that code got never commited.

OK. The current implementation doesn't match with the intention then.

> > however it also gets used
> > when dealing with filenames starting with a path variable. For example,
> > when it is enabled the filename Choices:Crypto.PuTTY.sshknownhosts gets
> > converted to Choices:Crypto/PuTTY/sshknownhosts which is not ideal. Can
> > anyone think of a situation when applying __RISCOSIFY_STRICT_UNIX_SPECS
> > to a filename starting with a path variable would be useful? If not,
> > I'll change it so it only gets applied to relative filenames.
> 
> The last sentence confuses me : I realise that you can question the
> usefulness of the current __RISCOSIFY_STRICT_UNIX_SPECS behaviour
> for Unix paths starting with a RISC OS path variable but I don't see
> why that would result in limiting its scope to only relative filenames.
> If you would do that, then I'm pretty sure my CVS port will break on it.

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.

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

Alex

-- 
Alex Waugh                                           alex at alexwaugh.com

PHP, Roots, Subversion, WebJames and more from http://www.alexwaugh.com/



More information about the gcc mailing list