summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorLines
2023-11-06remove non-prototype declaration of basename from string.hRich Felker-3/+0
commit 37bb3cce4598c19288628e675eaf1cda6e96958f suppressed the declaration for C++, where it is wrongly interpreted as declaring the function as taking no arguments. with C23 removing non-prototype declarations, that problem is now also relevant to C. the non-prototype declaration for basename originates with commit 06aec8d7152dfb8360cb7ed9b3d7215ca0b0b500, where it was designed to avoid conflicts with programs which declare basename with the GNU signature taking const char *. that change was probably misguided, as it represents not only misaligned expectations with the caller, but also undefined behavior (calling a function that's been declared with the wrong type). we could opt to fix the declaration, but since glibc, with the gratuitously incompatible GNU-basename function, seems to be the only implementation that declares it in string.h, it seems better to just remove the declaration. this provides some warning if applications are being built expecting the GNU behavior but not getting it. if we declared it here, it would only produce a warning if the caller also declares it themselves (rare) or if the caller attempts to pass a const-qualified pointer.
2017-10-13fix incorrect base name offset from nftw when pathname ends in slash(es)Rich Felker-3/+9
the rightmost '/' character is not necessarily the delimiter before the basename; it could be a spurious trailing character on the directory name. this change does not introduce any normalization of pathnames or stripping of trailing slashes, contrary to at least glibc and perhaps other implementations; it jusst prevents their presence from breaking things. whether further changes should be made is an open question that may depend on conformance and/or application compatibility considerations. based loosely on patch by Joakim Sindholt.
2012-05-09omit declaration of basename wrongly interpreted as prototype in C++Rich Felker-0/+2
the non-prototype declaration of basename in string.h is an ugly compromise to avoid breaking 2 types of broken software: 1. programs which assume basename is declared in string.h and thus would suffer from dangerous pointer-truncation if an implicit declaration were used. 2. programs which include string.h with _GNU_SOURCE defined but then declare their own prototype for basename using the incorrect GNU signature for the function (which would clash with a correct prototype). however, since C++ does not have non-prototype declarations and interprets them as prototypes for a function with no arguments, we must omit it when compiling C++ code. thankfully, all known broken apps that suffer from the above issues are written in C, not C++.
2012-02-24replace prototype for basename in string.h with non-prototype declarationRich Felker-1/+1
GNU programs may expect the GNU version of basename, which has a different prototype (argument is const-qualified) and prototype it themselves too. of course if they're expecting the GNU behavior for the function, they'll still run into problems, but at least this eliminates some compile-time failures.
2012-02-07declare basename in string.h when _GNU_SOURCE is definedRich Felker-0/+1
note that it still will have the standards-conformant behavior, not the GNU behavior. but at least this prevents broken code from ending up with truncated pointers due to implicit declarations...
2012-01-18alias basename to glibc name for it, to meet abi goalsRich Felker-0/+3
note that regardless of the name used, basename is always conformant. it never takes on the bogus gnu behavior, unlike glibc where basename is nonconformant when declared manually without including libgen.h.