It is a layer on top of C, so no change to the original “main” functions is needed. The C++ compiler can inline it. See this link, with an example implementation. https://lists.isocpp.org/std-proposals/2025/07/14583.php
I do not fully understand these extremely large arguments, but the standard is written with a fairly small limit, so I thought it might be of interest here to give it consideration. Yes, I also think it is a hack for a case when for some reason a pipe is not available, but it seems to be used regularly. >From the point of view of C++, std::string and std::vector might not be >suitable for such large arguments and possibly argument lists, but one can use >std::deque instead, which is also better for interactive allocations. Or >streams somehow. > On 24 Jul 2025, at 23:01, Niu Danny <[email protected]> wrote: > > I'd advise against calling that `main`, but name-mangling probably > come into place, then putting some kind of "decorator" on it may > have it invoked from the 'actual main'. > > Implementation-wise, this would require some way to pass the overly-large > argument set (ARG_MAX include both argv and environ btw) to the new > program - this can be done using anonymous pipe or memory-mapped file, > or some certain implementation-specific method (e.g. opening a process > as a file descriptor in FreeBSD, I'm not sure whether it can be > used for this purpose). The 'actual main' can then pick up those > argument set, construct the arguments and the environment class objects, > then pass it to the 'identifier-mangled' `main`. > > The 'actual main' in most implementations are actually an ordinary function > that's invoked by the entry point defined in a special object file - > this object file is injected into the program during linking (I think > they may be called "crt[01in].o" or something). This entry point > can in theory skip calling the so-called 'actual main', and invoke the > 'identifier-mangled' `main` directly instead.
