I have problem with your solution here. I just have the mindset that we in OpenBSD are well-positioned to educate upstreams when they make accidentally dangerous mistakes.
This entire 'get exec path' situation is incredibly bad. Some systems return non-realpath results. Other systems can return non-absolute paths. If the final filename is a hard-link to a different name, some systems can return the name of the link. I think I've found a system which can return the string "" and not call it an error. I've tried to design getexecpath(3) to have the most featureful, rich, and strict API, and hope in the next decade these rough-edges can be hidden inside a OS-portable wrapper which does this and brings strictness to the situation. Software like libuv can wrap their own layer on top of getexecpath. But their layer should try to be strict. We can't have an ecosystem of people in the industry railing against string truncation in strlcpy or snprintf which have correct return values, while other people build layers which intentionally perform string truncation of paths without error reporting. > Done: https://github.com/libuv/libuv/issues/5269 > > Since upstream can't reasonably implement either solution (or decide not > to change anything) before we released 8.0, can I get an ok for > https://marc.info/?l=openbsd-ports&m=178889314754679&w=2 then? > > On 9/9/26 12:07 AM, Theo de Raadt wrote: > > Please tell upstream of the concerns. > > Volker Schlecht <[email protected]> wrote: > > > >> ... alternatively, here's a simple wrapper around getexecpath(3), > >> with adjusted test cases to document where we deviate from upstream's > >> default behavior - might be harder to upstream once 8.0 is released, > >> but it's worth a shot. > >> > >> On 9/8/26 7:46 PM, Volker Schlecht wrote: > >>> Here's an attempt to switch libuv to getexecpath(3). > >>> It builds, tests pass, afaict it behaves the same as the other > >>> implementations (i.e. it copies a truncated path and no error > >>> when the path doesn't fit into the buffer). > >>> In lang/node it allows me to drop the current workaround to make > >>> process.execPath work. > >>> It could probably use some adult supervision, though ... > > >
