Filename handling changes - please read

John Tytgat John.Tytgat at aaug.net
Wed Dec 15 13:41:54 PST 2004


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

> In message <374fd61d4d.peter at chocky.org>
>           Peter Naulls <peter at chocky.org> wrote:
> 
> > In message <ebf9d21d4d.ajw498 at caramel.cp15.org>
> >           Alex Waugh <alex at alexwaugh.com> wrote:
> > 
> > > In message <cc00cb1d4d.peter at chocky.org>
> > >           Peter Naulls <peter at chocky.org> wrote:
> > > 
> > > > The changes to unixify mean that a file:  ADFS::4.$.c.file  now becomes:
> > > > 
> > > > /ADFS::4.$/file.c
> > > > 
> > > > instead of
> > > > 
> > > > /ADFS::4/$/file.c
> > > > 
> > > > I think this probably makes a bit more sense.
> > > 
> > > In what way does this make more sense? It looks to me like a special
> > > case that could cause confusion.
> > 
> > Perhaps, but this is the way it's always been in the programs using
> > rname.c.   However, the reason for this comment is that it causes
> > slightly less silliness with programs that chop up filenames to look at
> > different directories.  One example is the GTK file dialogue.
> 
> OK. Assuming riscosify copes with both formats, then I don't object.

Brr.  I'm feeling uneasy about this change.  The problem is that when there
are multiple Unix file specs matching the same RISC OS file spec, this
introduces all kinds of hairy issues in programs like CVS, because those
will typically via dirent recreate Unix filespecs which are potentionally
different with what you've started with.

I can't say yet whether Peter's changes introduced such issues in my CVS
port but I wouldn't be surprised if it would :-/.  Any volunteers to do
some testing ?

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