-
Notifications
You must be signed in to change notification settings - Fork 641
Description
per Linux Manpage:
There are two different versions of basename() - the POSIX version described above, and the GNU version, which one gets after
#define _GNU_SOURCE /* See feature_test_macros */ #include <string.h>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 "/". There is no GNU version of dirname().
With glibc, one gets the POSIX version of basename() when <libgen.h> is included, and the GNU version otherwise.
The inclusion of <string.h> to use basename() also breaks building outside of glibc, as seen in #4009's build log in TraceStream.cc.
If we keep using it, then we should explicit use the posix version by #include <libgen.h> in both current uses (only C++, in C we use a hard `strrchr(exe_image, '/').
So... What should it be (I'll do the PR):
- use posix version with a temporary copy of the c_str/data to a buffer and including the header
- use a C++ version with
- a hard
path.substrwithpath.find_last_of('/') + 1in both places - a wrapper function
base_namewhich allows also files without a path [not checking for nullptr as that is up to the caller], either defined in both files or a util header
- a hard
- something else (note: using
fs::path(exe_path).filename().string()won't work as the Wiki mentions RHEL7 and Ubuntu 14 - both don't have a compiler new enough installed per default; side note: I did not found an explicit minimal compiler version in the Wiki, but guess there must be one and the ancient GCC4.8/clang 3.4 distributed by those systems' package managers are possibly not working)