libc: Add get_current_dir_name()

[tobik]

Summary

It is a GNU extension that some ports have to patch away. Ports
replace it with just getcwd(NULL, 0) but it is technically not
really equivalent to that. It might be worth implementing it just
for that.

New description from get_current_dir_name(3):

get_current_dir_name() returns the value of the environment variable PWD if
it points to the current directory.  The value is returned verbatim.
Symbolic links will not have been resolved.  Relative paths will not have
been made absolute.  It falls back to getcwd(NULL, 0) otherwise.  The
return value must be freed.

Also here are the ones from the glibc manual:

• http://www.gnu.org/software/libc/manual/html_node/Working-Directory.html
• https://linux.die.net/man/3/getcwd

PR: 254092
Obtained from: musl libc

Test Plan

Cirrus CI build: https://cirrus-ci.com/task/5654091377410048

I'll ask for an exp-run once this looks ok.

[rpokala]

This appears to conform to the description of the Linux version:

get_current_dir_name() will malloc(3) an array big enough to hold the absolute pathname of the current working directory. If the environment variable PWD is set, and its value is correct, then that value will be returned. The caller should free(3) the returned buffer.

While I don't really understand why anyone would need the requested functionality (other than because "Linux" and/or because "glibc"), if there really is a need for this function, this seems to be a reasonable implementation of it.

I suggested some changes to the manpage, for better readability in English.

lib/libc/gen/getcwd.3

86

The function
.Fn get_current_dir_name

95

It falls back to
.Fn getcwd NULL 0
otherwise.

If
.Ev PWD
is unset or does not point to the current
directory,
.Fn get_current_dir_name
falls back to
.Fn getcwd NULL 0
.

[tobik]

Thanks for the review. I'll make the suggested manual changes later.

In D29182#658023, @rpokala wrote:

While I don't really understand why anyone would need the requested functionality (other than because "Linux" and/or because "glibc"), if there really is a need for this function, this seems to be a reasonable implementation of it.

This bothers me a whole lot. Did you really have to add a swipe on Linux or glibc? I wonder where exactly I have given the impression that my justification to want to import get_current_dir_name is "because Linux".

What actually triggered this review was that I ran into it a couple of time while porting myself and recently I saw rP567531 by @adridg who also had to waste time to implement get_current_dir_name unnecessarily. More people had to do it over the years too. All of that wasted porter and upstream time is way more costly than just having this function in libc.

[tobik]

• Update manual per suggestions

[tobik]

• Fix review contents hopefully

[rpokala]

In D29182#658119, @tobik wrote:

Thanks for the review. I'll make the suggested manual changes later.

This bothers me a whole lot. Did you really have to add a swipe on Linux or glibc? I wonder where exactly I have given the impression that my justification to want to import get_current_dir_name is "because Linux".

My apologies. :-(

I had intended just a small swipe at Linux and glibc for adding non-standard things for non-obvious reasons. Which of course results in us having to implement them too, for compatibility. I did not intend to impugn your or anyone else's motives.

What actually triggered this review was that I ran into it a couple of time while porting myself and recently I saw rP567531 by @adridg who also had to waste time to implement get_current_dir_name unnecessarily. More people had to do it over the years too. All of that wasted porter and upstream time is way more costly than just having this function in libc.

Fair enough.

With the change to the manpage, LGTM.

[emaste]

Any reason we don't want this change any longer?

[adridg]

The LGTM from the one reviewer seemed good enough; I never chimed in because .. well, this would fix retroactively the problem I had, but +1'ing things just for that did not seem necessary. It so happens the software where I added that implementation -- incomplete, since it doesn't follow PWD -- just had an update, so it's suddenly relevant for me again.