> On 25 Jul 2025, at 12:08, Niu Danny <[email protected]> wrote: > >> >> The OS can make a single allocation and mark out the C-strings with >> terminating null characters. > > Maybe, but not necessarily. Because the size of that argument buffer > mentioned by Harris > is a hard limit, a static configuration fixed throughout the operation of the > uptime of > the system. > > The ARG_MAX limit is small in the standard to cater to the small class of > systems, > i.e. embedded. Actual systems, such as servers, have larger limits. And it > *can* in theory > to be *configured* larger. > >> >> From my point of view, I just try to make C++ programming within the program >> more convenient, not affecting this at all. >> >> But the question was raised about these large arguments that people do use. >> Perhaps there should be some other mechanism to handle that. >> > > Alternatively, why not give "remote procedural calls" a try? It doesn't have > to be actually > remote. You can use local sockets for that purpose, or use a pair of pipes. > Argument of > that large size really should be handled as input data in my personal opinion. > > IIRC, Darwin systems have this XPC, and is a widely-used implementations of > local RPC. > RPC have the added benefit that you don't have to limit yourself to the > signature of "main". > > All in all, ARG_MAX is a **hard** limit, IO in general have fewer limits.
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. I am not sure what your suggestion is here: There surely ought to be better ways to write this program, but that option seems to not be available. Anyway, I have no use for it myself, only noticed that some have raised the issue.
