Use portable implementation for basename API

[kraj]

musl has removed the non-prototype declaration of basename from string.h [1] which now results in build errors with clang-17+ compiler

include libgen.h for using the posix declaration of the funciton.

Fixes
../git/tools/kmod.c:71:19: error: call to undeclared function 'basename'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
71 | "Commands:\n", basename(argv[0]));
| ^

[1] https://git.musl-libc.org/cgit/musl/commit/?id=725e17ed6dff4d0cd22487bb64470881e86a92e7
Signed-off-by: Khem Raj raj.khem@gmail.com

[lucasdemarchi]

But they are not the same. See VERSIONS @ https://man7.org/linux/man-pages/man3/basename.3.html

We pass in a const pointer and expect it not to be modified by basename()

[kraj]

But they are not the same. See VERSIONS @ https://man7.org/linux/man-pages/man3/basename.3.html

We pass in a const pointer and expect it not to be modified by basename()

ok, I thought it was not the case, however if we want to emulate the glibc behaviour we will need to create a temporary string and use it as input to basename(). This will let it use posix basename. Will that be ok ?

[lucasdemarchi]

I'd expect musl to have suggested change for this api breakage

[richfelker]

If the GNU basename behavior is really what's wanted, that can be achieved with basically a one-line function calling strrchr, something like:

static const char *gnu_basename(const char *s) {
    const char *p = strrchr(s, '/');
    return p ? p+1 : s;
}

[lucasdemarchi]

Thanks @richfelker. Yeah, using that as alternative sounds good to me.

[lucasdemarchi]

general approach in kmod is to consider the gnu-behavior as the desired one and add missing stuff for other libc's where appropriate. That way we don't have to keep patching kmod when the next .c uses basename() rather than gnu_basename().

[skarnet]

I understand that the GNU basename() behaviour is more desirable (and agree that it is), but the unfortunate fact is that the POSIX behaviour exists and is not going away; it's a bad move on GNU's part to have defined a symbol with a different prototype and a different behaviour from the POSIX one.

If I don't want the POSIX behaviour, I don't use basename(). I think that every project should do the same. I suggest that you go with gnu_basename(), and keep patching kmod because using basename() is suboptimal instead of keeping patching kmod because it breaks on some systems.

[kraj]

I think it would make it more readable for someone to make this difference clear rather subtle, but if you want to keep it obscure and assume basename is what glibc implements and not what posix defines, I will try to rework this to override basename when the system is not using glibc. Although, it will sound wrong for such non-gnu systems.

[lucasdemarchi]

My proposal is we do this: https://github.com/kmod-project/kmod/commits/tip-basename/

877280d fixup! fixup! Use portable implementation for basename API
3325c9d fixup! Use portable implementation for basename API
81580c1 Use portable implementation for basename API

I think we can just squash my commits onto yours if you agree.

[lucasdemarchi]

I should probably split the missing.h, but that can be done on top.

[skarnet]

That will work as long as the project never includes libgen.h. Which, true, it doesn't have a reason to.

[kdave]

I fixed the basename semantics in btrfs-progs and got pointed to this PR for a fix. You may need to add handling of "/" as special case, this is mentioned in the manual page that basename is supposed to return that as "/", i.e. the strrchr() would return empty string.

[lucasdemarchi]

@kdave thanks for reaching out. However this is not what I get. :

# glibc
/foo/bar/: 
/foo/bar: bar
/foo: foo
/: 
:

# musl  with special / handling
/foo/bar/: 
/foo/bar: bar
/foo: foo
/: /
:

Checking the man page, it explicitly calls out that in case of '/' it returns the empty string. Emphasis mine:

The GNU version never modifies its argument, and returns the empty string when path has a trailing slash, and in particular also when it is "/".