> No Gambit does not use realpath() because it is more portable in my experience to use the pattern:
>
>    chdir(dir);
>    getcwd(normalized_dir, len);
>
> with a lock around that to avoid interference with other OS threads when configured with --enable-multiple-threaded-vms .
>
> Maybe lib/os_files.c should be extended to allow using realpath() if it is available.

Your getcwd() approach may infact be smarter. getcwd() is only specified
to return guarantees an absolute path, whereas realpath() needs to
resolve symlinks as well.

<https://pubs.opengroup.org/onlinepubs/9699919799/functions/getcwd.html>

That page also has a warning about the possibility of getcwd() failing,
I don't know how relevant this scenario is:

> If a program is operating in a directory where some (grand)parent directory does not permit reading, getcwd() may fail, as in most implementations it must read the directory to determine the name of the file. This can occur if search, but not read, permission is granted in an intermediate directory, or if the program is placed in that directory by some more privileged process (for example, login). Including the [EACCES] error condition makes the reporting of the error consistent and warns the application developer that getcwd() can fail for reasons beyond the control of the application developer or user. Some implementations can avoid this occurrence (for example, by implementing getcwd() using pwd, where pwd is a set-user-root process), thus the error was made optional. Since this volume of POSIX.1-2017 permits the addition of other errors, this would be a common addition and yet one that applications could not be expected to deal with without this addition.