| 28 Dec 2025 |
 Ihar Hrachyshka | where does one define common CFLAGS / CPPFLAGS for darwin? | 23:17:43 |
| Ihar Hrachyshka | * where does one define common CFLAGS / CPPFLAGS for darwin? (for all nixpkgs) | 23:18:00 |
 Randy Eckenrode | Usually in the wrapper. What flags? | 23:21:52 |
| Ihar Hrachyshka | the ones for SET_FDSIZE increase | 23:52:09 |
| Ihar Hrachyshka | is it the wrapper postFixup? | 23:54:47 |
| 29 Dec 2025 |
| Ihar Hrachyshka | is it something like this? https://github.com/NixOS/nixpkgs/pull/474914 | 00:01:45 |
| Randy Eckenrode | That looks reasonable. | 00:28:13 |
 emily | can you explain "except the need to pass POSIX certification"? | 00:38:13 |
| Randy Eckenrode | POSIX requires that select return EINVAL when nfds is larger than SET_FDSIZE. | 00:39:37 |
| Ihar Hrachyshka | there's some more info in https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4953
but basically "POSIX requires EINVAL if nfds >= FD_SETSIZE" | 00:39:45 |
| Randy Eckenrode | Which is 1024 AFAIK for historical reasons. | 00:40:02 |
| Randy Eckenrode | Darwin has a way to allow bigger sizes, but you have to opt into it. | 00:40:53 |
| emily | I'm not a fan of setting global compiler flags that diverge from the platform defaults and that can result in programs having hidden security vulnerabilities when compiled with standard flags. _DARWIN_UNLIMITED_SELECT especially is a kind of crazy hack | 00:41:10 |
| emily | programs that need/can handle such a definition should set the flags themselves in their own build systems | 00:41:28 |
| Randy Eckenrode | The only issue I can see with forcing a larger size for all packages is what happens when packages request their own size (e.g., a smaller one). | 00:42:00 |
| emily |
This will not resolve the issue of fds limited to 1024 per se but only
disable the fault trap in libSystem. To increase the number of fds
supported by select, one also has to increase FD_SETSIZE macro value
during compilation, making sure it's defined before select header is
included.
I believe the idea is actually that you pass a heap-allocated fd buffer instead
| 00:42:21 |
| emily | and then it checks whether it's on the stack or not | 00:42:34 |
| Ihar Hrachyshka | ...which is what I'm doing in that glib patch (and in the counterpart local to glib package here: https://github.com/NixOS/nixpkgs/pull/474904) but we had a discussion with Randy the other day that maybe there's no practical reason to limit it (BSDs don't) | 00:42:43 |
| Randy Eckenrode | The implementation in xnu just disables the check. It doesn’t check location AFAIK. | 00:43:11 |
| emily | POSIX doesn't say FD_SETSIZE has to be 1024, so Apple could raise the default if they wanted to (so perhaps there is a reason they haven't) | 00:43:41 |
| Ihar Hrachyshka |
I believe the idea is actually that you pass a heap-allocated fd buffer instead
interesting. and it rhymes with something we read elsewhere. where do you get this from?
| 00:43:54 |
| emily | one obvious way it can go badly is if people cast their own 1024-size stack buffers to fd_set and then you have a heap overflow vulnerability | 00:44:10 |
| Randy Eckenrode | Wouldn’t that be a breaking change? | 00:44:12 |
| emily | well, no more or less a breaking change than if we do it | 00:44:39 |
| Randy Eckenrode | https://github.com/apple-oss-distributions/xnu/blob/f6217f891ac0bb64f3d375211650a4c1ff8ca1ea/libsyscall/wrappers/select-base.c#L10 | 00:44:40 |
| Randy Eckenrode | * | 00:44:46 |
| emily | nominally it should just increase people's stack sizes, but ^ could potentially cause disaster, but then that's a reason it could be bad for us too | 00:44:59 |
| Randy Eckenrode | But we’re building everything from source. Apple has to support older binaries. | 00:45:17 |
| Randy Eckenrode | https://devblogs.microsoft.com/oldnewthing/20221102-00/?p=107343 | 00:45:40 |
| Randy Eckenrode | Apple is kind of stuck with a crappy ABI it inherited from BSD. | 00:46:00 |
