Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
More robust determination of full path to current executable #795
The OCaml runtime system has some system-dependent code (Linux, Windows) to recover the full path to the current executable, in ways that are more reliable than searching
Previously, this code worked only for paths of 256 characters or less, owing to the static allocation of a buffer.
Some OCaml users informed us that this limitation was cramping their style and that executables with very long names indeed are important to their business. "Surely you must be joking?" questions were answered with utter seriousness.
Always happy to help OCaml users do the weirdest things, I offer in this PR a reimplementation of these parts of the runtime where the buffer for the full path name is allocated dynamically and grows on demand.
As a bonus, special code to determine the path to the executable was added for Mac OS X as well, courtesy of informative StackOverflow posts.
The new code was tested under Linux, but not even compiled under Mac OS X nor under Windows. Caveat emptor.
I used the CI machines to check that the compiler builds fine under MacOS, mingw and mscvc machines with the proposed changes. Could you maybe include a test that uses a super-duper-long executable name to actually test the new behavior?
There is a very suspicious CI failure on openbsd32, a segfault while running an innocuous typing test of the testsuite: see "Segmentation fault" in the logs https://ci.inria.fr/ocaml/view/precheck/job/precheck-openbsd-32/2/consoleText . I don't know where this comes from, and asked for a new build to see if it is reproducible but the results are not in yet.
Edit: the new openbsd32 build succeeded, so the observed segmentation fault (while testing
In case anyone is curious, the crazy organization that runs into this is Jane Street. The problem comes up when we take a large change and break it into a long sequence of small patches, each dependent on the last. This is represented in our code review system as nested directories, one per patch. We don't often cross the 256 character limit, but when someone does, it's annoying.
So, while we're not joking, it doesn't mean we don't appreciate that our request is a little absurd.
Anyway, thanks for the patch!