Isn't this case the motivation for readlinkat?

I'm not sure I understand what you are meaning?

From reading the man page of readlinkat it seems it's difference is that you can provide a directory file descriptor from which to interpreted a passed relative path from instead of a implicitly relative to the processes working directory.

The race condition I was referring to was that, in the original code, the length of the symlink was determined by a call to stat while the contents of the symlink was determined by a later call to readlink. This can go wrong as things can technically change between the two calls.

The value used for the length of the returned symlink should be the value that readlink returns, as it is the one that also provides the symlink contents, not the earlier stat value.

Cheers! -Tyson

PS: My motivation for this change isn't so much that I'm worried about this race condition, although it should be fixed as it is technically wrong and can be, but that the stat call on our (vendor supplied) filesystem is broken and returns the length +1 which screws up the current code.

Oh, I see, sorry. Ignore me!

Since we're allocating the temporary value on the stack anyway, I would just directly allocate a PATH_MAX sized buffer.

Apparently PATH_MAX is a bit of a dubious thing

http://www.gnu.org/software/libc/manual/html_node/Limits-for-Files.html

and isn't even defined on some OSs.

Golang implements readlink as in this PR: https://sourcegraph.com/github.com/golang/go@go1.9.2/-/blob/src/os/file_posix.go#L16-29

@orivej Interesting. Looks exactly like what I did except they start with a length of 128 and do 2x on failure while I started with 1024 (PATH_MAX/4) and do 1.5x on failure.

Perhaps picking a value like 128 is better though as on some systems PATH_MAX is not defined.

According to git blame, the code originally just used the stat size, but was later amended to use max(stat size,PATH_MAX) as links in /proc returned a stat size of 0.