diff dynload/dynload.3 @ 315:3840e0188520

- allowing lookup of running executable's path by passing NULL to dynload's dlGetLibraryPath()
author Tassilo Philipp
date Wed, 06 Nov 2019 14:13:49 +0100
parents 7c6f19d42b31
children 3df50603afa9
line wrap: on
line diff
--- a/dynload/dynload.3	Wed Nov 06 12:32:53 2019 +0100
+++ b/dynload/dynload.3	Wed Nov 06 14:13:49 2019 +0100
@@ -80,7 +80,9 @@
 .Ar bufSize
 >= return value >= 1, a null-terminted string with the path to the library should be in
 .Ar sOut .
-If it returns 0, the library name wasn't able to be found. Please note that this might happen in some rare cases, so make sure to always check.
+If it returns 0, the library name wasn't able to be found. Please note that this might happen in some rare cases, so make sure to always check. Passing a null pointer as
+.Ar pLib
+returns the path to the executable (not guaranteed to be absolute).
 .Pp
 The dlSyms* functions can be used to iterate over symbols. Since they can be used on libraries that are not linked, they are made
 for symbol name lookups, not to get symbols' addresses. For that refer to
@@ -101,14 +103,22 @@
 .Sh BUGS
 .Fn dlGetLibraryPath
 is not thread-safe on Darwin (macOS, iOS, ...) and OpenBSD.
+.Pp
 .Fn dlSymsInit
 is not thread-safe on Darwin.
+.Pp
 .Fn dlGetLibraryPath
 will not work on the following platforms when the library in question doesn't have the (default)
 .Fn _init
 and
 .Fn _fini
 symbols exported (rare, but possible): Haiku (all versions), OpenBSD < 3.7, NetBSD < 5.1, FreeBSD < 4.8
+.Pp
+Getting the executable's path by passing NULL in
+.Ar pLib
+to
+.Fn dlGetLibraryPath
+fails on the following platforms: Haiku (all versions), OpenBSD < 3.7, NetBSD < 5.1, FreeBSD < 4.8
 .Sh CONFORMING TO
 The dynload library conforms to c99.
 .Ed