On 2026-07-27 05:30:43+0200, Willy Tarreau wrote:
> On Sun, Jul 26, 2026 at 10:16:42PM +0200, Thomas Weißschuh wrote:
> > On 2026-07-26 17:13:02+0700, Ammar Faizi wrote:
> > (...)
> >
> > > +#define __nolibc_syscall_eval6(_n, _a1, _a2, _a3, _a4, _a5, _a6) \
> > > +({
> > > \
> > > + __auto_type __sc_n = (_n); \
> > > + __auto_type __sc_a1 = (_a1); \
> > > + __auto_type __sc_a2 = (_a2); \
> > > + __auto_type __sc_a3 = (_a3); \
> > > + __auto_type __sc_a4 = (_a4); \
> > > + __auto_type __sc_a5 = (_a5); \
> > > + __auto_type __sc_a6 = (_a6); \
> >
> > __auto_type is only supported from GCC 4.9. I think this is old enough,
> > but it should be mentioned at least.
>
> Well, at other places we already have typeof(arg) which is exactly the
> same, more explicit, and doesn't come with such restrictions, so I'd
> rather suggest we use it instead.
Agreed.
> > We really should have a documented policy for that.
>
> We could indeed. Till now the principle has been not to break support for
> older compilers without a really good reason (i.e. something that would
> become too complicated or impossible to do). At least we should add a
> README in the directory indicating what is oldest supported version, as
> it really doesn't cost anything to preserve support for that for a long
> time.
Also agreed. I don't want to intentionally break older compilers.
But if we know where the baseline is today we don't have to have
discussions about changes which would *not* violate said baseline
anyways.
Also as mentioned by you before, we should not tie ourselves to the
general kernel baseline. nolibc is much simpler and doesn't have
the same requirements.
> > > + __nolibc_syscall6(__sc_n, __sc_a1, __sc_a2, __sc_a3, __sc_a4, \
> > > + __sc_a5, __sc_a6); \
> > > +})
> > > +
> > > #define ___nolibc_syscall_narg(_0, _1, _2, _3, _4, _5, _6, N, ...) N
> > > #define __nolibc_syscall_narg(...) ___nolibc_syscall_narg(__VA_ARGS__,
> > > 6, 5, 4, 3, 2, 1, 0)
> > > -#define __nolibc_syscall(N, ...) __nolibc_syscall##N(__VA_ARGS__)
> > > +#define __nolibc_syscall(N, ...) __nolibc_syscall_eval##N(__VA_ARGS__)
> >
> > I'd like to apply the same thing to the __nolibc_syscallN()
> > usage within nolibc itself. While today we seem not to have any
> > problematic cases, at least I was not aware of the issue and breakage
> > might creep in accidentally. We can problably rename the
> > architecture-specific macros to __nolibc_syscall_archN()
> > and make __nolibc_syscall() the properly evaluating wrapper.
>
> Yes, I wasn't aware of that either. Also I'd like to recheck that
> MIPS continues to work fine because I seem to remember that its
> constraints tend to be harder to respect in syscall6() and it took
> us a few times to get it right. But maybe this could have helped
> instead.
Ack.
Thomas
