Hi Thomas, hi Ammar,
On Sun, Jul 26, 2026 at 10:16:42PM +0200, Thomas Weißschuh wrote:
> Thanks!
>
> 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.
> 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.
> > + __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.
willy
