Why would an implementation of getwd call mktemp?

Question

As mentioned here the book Expert C Programming contains the claim that there was a bug in SunOS 4.0.3's version of lpr, (a printing program) caused by a custom mktemp function overriding the library function of the same name when called by getwd.

The example code describing the problem was:

my_source.c

mktemp() { ... }

main() {
  mktemp();
  getwd();
}

libc

mktemp(){ ... }
getwd(){ ...; mktemp(); ... }

My assumption is that getwd is meant to get the current working directory, and mktemp is meant to make a temporary file name, like, if not identical to the linux functions with the same names.

My question is, why would getwd call mktemp? That is, why would the function to get the working directory, need to make a temporary file name?

The only possible reason I can think of is that sometimes you end up with a process that doesn't have a real working directory, so a temporary one is returned. But that doesn't seem likely to me. Also, if that was the reason, why would processes end up without working directories often enough that it was a noticeable problem?

Answer 1

If you look into the source code for SunOS 4.1.4, available online, getwd() is not a simple function.

It actually walks up the directory tree, performing all sorts of wonderful tasks to get the name of the parent directory and prefix it to your current directory name. It does that because it wants to get an absolute location, independent of any hard links, mounts across device boundaries, and other file-system trickery like circular links.

In other words, it wants to ensure that things like /1/2/3/4/5/4/6 (where that 5 is a hard link back to the 3) give you the correct /1/2/3/4/6 (it's more than just . and .. that can cause this issue).

Hence it calls stat("./") to get device information of your current directory, then continuously calls stat("../") to walk up the tree, checking things like device crossings and so on. It only stops when it comes to the root of the entire hierarchy (the parent is the same device and inode as the current).

While this version of the code doesn't mention mktemp, it seems plausible to me that an earlier one may have resorted to the use of that function to (for example) establish whether a particular directory was accessible to the user. The code linked to simply checks whether the stat call returned an error but I've not been able to find the 4.0.3 source in easily accessible format.