On Jul 26, 2025, at 5:46 AM, Hans Åberg <[email protected]> wrote:
> On 25 Jul 2025, at 22:37, Guy Harris <[email protected]> wrote: > >> On Jul 25, 2025, at 6:07 AM, Hans Åberg <[email protected]> wrote: >> >>> They have a given program, which they cannot change, but apparently can >>> accept 256 kB of text in arguments, and the preferred workaround is to >>> recompile the kernel. >> >> On which kernel is this? As per my earlier mail, one version of the Darwin >> kernel (macOS, iOS, etc.) has a 1 MB ARG_MAX (and it's , and one version of >> the Linux kernel has a 2 MB ARG_MAX. My Solaris 10 VM also reports 1 MB, and >> *that* limit dates back to at least SunOS 4.0. So *those* kernels have an >> ARG_MAX that's 4x to 8x larger than 256 kB; even if you have a *lot* of >> environment variables, that shouldn't be a problem. >> >> "Recompile the kernel" doesn't apply to AIX or HP-UX or other commercial >> UN*Xes; is this a *BSD or something such as that? > > It is in the link in my first post, detailing how to do it on a Linux kernel. > One can also take down and compile XNU, with people on their mailing list > asking how to do it. The problem here appears to be that the Linux kernel is "helpfully" imposing its own length limitation *on top of* the ARG_MAX; the maximum length of an *individual string argument* is not a limit specified in POSIX, and one might argue that the Linux kernel is not POSIX-compliant here. Given that, at some points in the past, both Inspur K-UX 2.0 (https://en.wikipedia.org/wiki/Inspur_K-UX) and some version of EulerOS (https://en.wikipedia.org/wiki/EulerOS), both Linux distributions based on Red Hat Enterprise Linux, were certified as UNIX and thus, presumably, passed some version of the Single UNIX Specification validation suite. Perhaps that suite doesn't check whether passing, for example, an argument list in which argv[0] is ARG_MAX bytes, and no environment, is passed to an exec call, so it doesn't catch that annoying Linux issue. So this is a problem to report to the Linux kernel developers, as it's the result of their decision to limit the size of individual arguments (and probably individual name=value elements in the environment). It's not a POSIX issue, as POSIX doesn't impose such a limit, it just imposes a limit on the total number of bytes passed. One way to work around this might be to have the program being executed have a way of combining multiple sequential argument strings into a single argument string and have the executing program or shell script break long arguments into fragments and indicate to the program being executed that it must reassemble them.
