Page MenuHomeFreeBSD

Replace basename(3) by a thread-safe implementation.
ClosedPublic

Authored by ed on Oct 29 2016, 7:42 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mar 10 2024, 9:45 PM
Unknown Object (File)
Mar 10 2024, 9:35 PM
Unknown Object (File)
Mar 10 2024, 9:35 PM
Unknown Object (File)
Mar 7 2024, 9:57 PM
Unknown Object (File)
Mar 3 2024, 10:30 AM
Unknown Object (File)
Feb 19 2024, 6:30 PM
Unknown Object (File)
Feb 4 2024, 3:36 PM
Unknown Object (File)
Jan 6 2024, 6:04 AM
Subscribers

Details

Summary

Now that the changes to the dirname(3) function had some time to settle,
let's go ahead and use the same approach for replacing basename(3) by a
simple implementation that modifies the input string, thereby making it
thread-safe and guaranteed to succeed.

Unlike dirname(3), this function already had a thread-safe variant
basename_r(3). This function had its own set of problems, like having an
upper bound on the pathname length. Keep this function around for
compatibility, but remove most references from the man page. Make the
man page more similar to that of dirname(3).

As the basename_r(3) function is only provided by FreeBSD (and Bionic),
depending on its use is even more implementation defined than assuming
that basename(3) is thread-safe.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

ed retitled this revision from to Replace basename(3) by a thread-safe implementation. .
ed updated this object.
ed edited the test plan for this revision. (Show Details)
ed added reviewers: emaste, wblock, jilles.
ed set the repository for this revision to rS FreeBSD src repository - subversion.
emaste edited edge metadata.
emaste added inline comments.
lib/libc/gen/basename_compat.c
81 ↗(On Diff #21796)

Our naming convention is rather unfortunate.

This revision is now accepted and ready to land.Nov 3 2016, 5:10 PM
lib/libc/gen/basename_compat.c
81 ↗(On Diff #21796)

Of our symbol version namespaces? Yeah, I also don't like it. :-/

This revision was automatically updated to reflect the committed changes.

Sorry for the late reply... no major complaints. For the future, remember that "may" usually implies permission ("yes, you may overwrite that file now"), while "might" is usually better to use to say that something might or might not happen: "this function might return a pointer to a random area of memory". Also, try to avoid "the former" or "the latter", because it forces the reader to stop and look back to see which is which.

Thanks for your work!