getcwd C function

I have noticed that the getcwd function with SharedUnixLibrary returns a non-RISCOS compliant directory structure. I use :

temp=(char *) SDL_malloc(size);
if (temp)
{
getcwd(temp,size-1);
}

return temp;

and the returned path is :

/HostFS::HostFS.$/Public/Programming/C/Triority/Source

Programs built using Unixlib use unix-style filenames by default. You should be able to override the behaviour by declaring and initialising the global __riscosify_control variable, e.g.:

#include <unixlib/local.h>
int __riscosify_control = __RISCOSIFY_NO_PROCESS | __RISCOSIFY_NO_REVERSE_SUFFIX;

The unixlib/local.h header is located at !GCC.arm-unknown-riscos.include.unixlib.h.local, and contains an explanation of the different options.

Note that although __RISCOSIFY_NO_PROCESS supposedly disables all processing, I found I had to also set __RISCOSIFY_NO_REVERSE_SUFFIX to get opendir to behave correctly.

That seems to be better – thanks.

/HostFS::HostFS.$/Public/Programming/C/Triority/Source

That looks quite normal for unixlib, it does work internally with unix paths and when encountering RISC OS it has to convert them for use. The riscosification of paths is only to be user friendly at the stdout/stdin, but ports can be used from the CLI in the unix format equally. Steps can be taken to alter the behaviour, but the standard usually works OK.
It sounds like you have found a reason to riscosify, perhaps that path is not working?
There is a bug where you can not disable norcroft style suffixes, so you can find a problem where your port will behave like it is a gcc binary and swap the sfix directories when it shouldn’t. (__RISCOSIFY_NO_SUFFIX or something similar)

Yes, what was happening is that instead of creating a directory of x and then y, it was creating a directory of x/y…