Re: Proposal: getexecpath(3)

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Sun, 25 Oct 2026 04:20:57 -0400
> From: Brad Smith <brad%comstyle.com@localhost>
> 
> So the name is the same, but both the signature and the semantics
> differ from what is proposed here: a canonical absolute path rather
> than the verbatim execve(2) argument. If NetBSD goes ahead with
> this, it would be good to either match OpenBSD's interface or pick a
> different name.

Why do you want the kernel to compute some notion of a canonical
absolute path?  Of what use is this for applications?  Isn't this
strictly less useful than the original verbatim exec path?

You can always pass the original verbatim exec path to realpath(3) if
you want to canonicalize it, but you can't undo realpath(3) (or the
kernel's equivalent) if the program wants to use the same symlinks for
to (dl)open supporting data and libraries as the caller used to
execute the program.

I think it is a mistake for the kernel to expose anything other than
the original verbatim exec path.

(I don't have strong feelings about char *getexecpath(void) vs void
getexecpath(char *, size_t); the first one is a little simpler, but
whatever.)

> Portable software is already starting to probe for getexecpath()
> (HAVE_GETEXECPATH checks in configure/meson/CMake), and two
> incompatible functions under the same name would be an unpleasant
> trap.

Sounds like the `portable' software needs #ifdef __OpenBSD__, since
API this isn't portable to any platform except OpenBSD anyway?