> What's the advantage of the _1, _2 etc. forms? Now that you mention it... I don't believe there are any.
> The compiler knows how many arguments you're passing, > why can't there just be one built-in handling all cases? You're right about that. When I started working on this I just mirrored the existing APIs which consist of one function for each possible arity. I have always wanted a variadic system call function though so when I saw that GCC had variadic builtins I threw one in. A builtin doesn't have the overhead of variadic C functions though. The compiler should be able to generate optimal code depending on how many arguments it's called with. It's the best possible interface and strictly superior to anything libraries can offer. Would other languages supported by GCC benefit from the other forms? Perhaps variadic builtins are incompatible with them for some reason? I can't think of any reason to keep the numbered forms otherwise. > Your proposal doesn't seem to actually address the problem. > If using the clone syscall causes problems for glibc by not > giving glibc a chance to set up TLS etc for the new thread, > how does making it easier to use the clone syscall help? I think that problem can never be fully addressed, only worked around. It seems to be inherent to how standard C libraries are implemented. The C standards apparently make it impossible to avoid either global or thread local state. Locales come to mind... Compiler support for system calls help by eliminating the need for the system call stub functions traditionally provided by these C libraries. There's no need to link against the C libraries just for that anymore and there's also no need to implement it ourselves since the compiler provides it. The result is it makes it easier to develop freestanding software targeting Linux.
