Replace dirname(3) by a copy that complies to POSIX.

[ed]

Summary

It turns out that the path normalization that our brand new copy of
dirname(3) does is actually not allowed by the draft version of the
upcoming version of POSIX. It has to behave identically to the
dirname(1) utility.

This change replaces our new dirname(3) implementation by yet another
version that doesn't implement the path normalization logic; it merely
looks for the end of the directory name and overwrites that with a null
byte.

More details: See note #3370 at http://austingroupbugs.net/view.php?id=1073

[emaste]

lib/libc/gen/dirname.c

58–59 ↗

(On Diff #20064)

should we return "." here like line 42?

[jilles]

Looks good otherwise.

lib/libc/gen/dirname.c

42 ↗

(On Diff #20064)

This does not compile at high warning levels that include -Wcast-qual, where DECONST would be necessary.

58–59 ↗

(On Diff #20064)

Given that we must return static storage above, it doesn't seem to make much sense to avoid static storage here.

[ed]

lib/libc/gen/dirname.c

58–59 ↗

(On Diff #20064)

There is a tiny reason why I went with this approach:

With this implementation we only return constant/static storage in case the provided path is NULL or empty, which is very likely almost never the case. As basename() and dirname() also never return empty strings, this means that we can safely perform successive calls on the same input string without attempting to modify constant data.

For example, with this version it is safe to call basename(dirname(x)), basename(dirname(dirname(x))), etc. to obtain the names of individual pathname components, as long as x is not empty.

Thoughts?

[emaste]

lib/libc/gen/dirname.c

58–59 ↗

(On Diff #20064)

Ok, that's fair. Although I think it's possible to accommodate that use having the returned string be writeable seems sensible.

[ed]

Use __DECONST().

[ed]

So is this change good to go? :-)