Closed sswam closed 3 years ago
The behavior is operating system dependent, I'm guessing you are running on Linux, as looking at a Linux dirname(3)
man page:
Bugs
In the glibc implementation of the POSIX versions of these functions they modify their argument
At least this is correctly recognized as a bug in glibc. Your patch looks good, and should still work in cases where dirname(3)
doesn't modify the argument. I'll test and merge shortly.
There's no good way to implement dirname
with that API. I looked it up, POSIX suggests and allows two bad alternatives:
RETURN VALUE
The dirname( ) function shall return a pointer to a string that is the parent directory of path. If
path is a null pointer or points to an empty string, a pointer to a string "." is returned.
The dirname( ) function may modify the string pointed to by path, and may return a pointer to
static storage that may then be overwritten by subsequent calls to dirname( ).
NetBSD for example does it the other way, returning a pointer to static storage (that may be overwritten). GNU is complaining that the POSIX definitions of dirname and basename are bad because they lead to bugs. It's a bug in POSIX, not a bug in glibc.
dirname modifies its argument, so it would try to create ~/.config twice, giving an error.