John Tytgat John.Tytgat at aaug.net
Mon Jan 10 14:21:35 PST 2005

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.

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

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 ?

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