Changes made in GCCSDK for CVS

John Tytgat John.Tytgat at
Mon Oct 14 14:42:40 PDT 2002

In message <042742854b.peter at>
          Peter Naulls <peter at> wrote:

> In message <805ed7844b.peter at>
>           Peter Naulls <peter at> wrote:
> > I've just today found a bug in 'make' whereby object files of type data
> > (e.g. Norcroft output) are always remade, as 'make' thinks they don't
> > exist.  I suspect this is a bug in unixlib somewhere, and likely it's
> > your same bug.  I will probably look at this tommorow.
> And here's why (unix/stat.c):
>   if (regs[0] == 0
>       || (sftype != __RISCOSIFY_FILETYPE_NOTFOUND && sftype != aftype))
>     return __set_errno (ENOENT);
> If the existing object file is typed data, sftype ends up being fff and
> aftype is ffd.   I'm confused by what this logic is supposed to do -
> John, is it part of your charges to filetype handling?  Should there be
> a special case for text?  Should riscosify be doing something different?
> For the moment in my version I'll put in a special case for fff.

Let me try to explain it :

- stat() gathers info on a given Unix filename
- __riscosify_std() converts the Unix filename into a RISC OS filename
  and iff __RISCOSIFY_FILETYPE_FFF_EXT is specified *and* a RISC OS filetype
  is specified in the Unix filename (i.e. using the ",xyz" filetype
  extension), we will get it in 'sftype', otherwise 'sftype' ==
  [ So Peter, when you say "If the existing object file is typed data, sftype
    ends up being fff", that doesn't sound right to me.  It should be -1
    set, or 0xFFD when __RISCOSIFY_FILETYPE_SET is unset. ]
- We now check the existence of the file using the RISC OS filename only
  using __os_file().
  If such a file using the RISC OS filename is found, we extract the
  RISC OS filetype in 'aftype'.
- We only have a successful stat() iff the RISC OS __os_file() routine
  && (sftype == __RISCOSIFY_FILETYPE_NOTFOUND [1] || sftype == aftype [2])
  [1] = this means the filetype is not specified (like "/dir1/dir2/my_file"
        will match "$.dir1.dir2.my_file" (any filetype)
        or we don't want filetype extension
        Note: the 1st case can be tricky as this is not bijective, like
        when you go from "$.dir1.dir2.my_file" (any filetype) to Unix again
        (assume __RISCOSIFY_FILETYPE_SET is set), you will end up with
        "/dir1/dir2/my_file,xyz" which is different than
        "/dir1/dir2/my_file" !
  [2] = this means the filetype is specified (like "/dir1/dir2/my_file,fe1"
        will *only* match "$.dir1.dir2.my_file" with 0xFE1 filetype.

  This also means, we have a fail when __os_file() failes (i.e. regs[0] == 0)
  || (sftype != __RISCOSIFY_FILETYPE_NOTFOUND && sftype != aftype).
  This is exactly what is written in the code.

BTW, the exception with filetype 0xFFF is the __RISCOSIFY_FILETYPE_FFF_EXT

- When set : filetype 0xFFF is not an exception in the filetype mapping, i.e.

  RISC OS                                   Unix
  $.dir1.dir2.text_file (filetype Text) <-> /dir1/dir2/text_file,fff
  $.dir1.dir2.data_file (filetype Data) <-> /dir1/dir2/text_file,ffd
- When unset : filetype 0xFFF is implicitly assumed for all Unix files
  without filetype extension :
  $.dir1.dir2.text_file (filetype Text) <-> /dir1/dir2/text_file
  $.dir1.dir2.data_file (filetype Data) <-> /dir1/dir2/text_file,ffd

I think this might be the problem.  Because as __RISCOSIFY_FILETYPE_FFF_EXT
is unset in 'make', there is a possible non bijective mapping between
/dir1/dir2/data_file (specified *without* filetype extension in the Makefile
!!!) in Unix -> $.dir1.dir2.data_file in RISC OS when when going back to
Unix this becomes /dir1/dir2/data_file,ffd which is different from
/dir1/dir2/data_file so your Makefile rule gets always executed.

So test the following : specify the (Unix) data filenames in your Makefile
with ",ffd" filetype extension.

Anyway, if you don't want want any filetype extension code be activated,
the only filetype you may get from riscosify() is

Does this make sense ?

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

More information about the gcc mailing list