Rafael Sadowski <rafael@sizeofvoid.org> wrote: > On Tue Sep 08, 2026 at 08:47:12PM +0200, Volker Schlecht 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. > > I like this version better, but do you think upstream will accept it? > Why not just hide the getexecpath(3) handling behind "__OpenBSD__" and leave > the old version unchanged? Their function behaviour has got some very dangerous aspects. It generates truncated garbage and does not return error. Something about the executable-path attracts the worse designs. I have a list of near 10 weird things the various low-level and mid-level APIs generate as outcome, and these are unreliablity concerns in the upper-level libraries of applications. It is so sloppy.
Tuesday, September 08, 2026
Re: devel/libuv: use getexecpath(3)
On Tue Sep 08, 2026 at 08:47:12PM +0200, Volker Schlecht 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. I like this version better, but do you think upstream will accept it? Why not just hide the getexecpath(3) handling behind "__OpenBSD__" and leave the old version unchanged? > > 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 ...