Hey, > Looking at the change, it seems to be circumventing the fact that > syscall() is not really defined on GNU/Hurd. Instead of defining > arbitrary values for TSOCKS_NR_*, we could as well put the syscall > redirection code inside #ifndef __GNU__ since there is nothing to > redirect, applications running on GNU/Hurd won't ever be using > syscall().
Thanks for your fast explanation. Okay digging deeper into the code I see, that also the linux part on compat.h has these numbering [1]. So it is not that uncommon. [1] https://salsa.debian.org/pkg-privacy-team/torsocks/-/blob/debian/sid/src/ common/compat.h?ref_type=heads#L74 The change on configure.ac I understand, that this reflects in the correct libc version. But buildd is actually fine with the configure step, so is that still needed? torsocks.h okay it changed their hunks, but seems fine. I think the change on syscall.c is not needed anymore, as they changed to negative logic [2]. https://salsa.debian.org/pkg-privacy-team/torsocks/-/blob/debian/sid/src/lib/ syscall.c#L87 I now have a feeling, that I understand and could ask upstream, if you can update the patch for the new version. At least hunks have changed and it would be nice if we propose a working patch for upstream. I'm a little bit lost in the preprocessor macros. Is __GNU__ only only true for Hurd? Regards, hefee
signature.asc
Description: This is a digitally signed message part.
