| 29 Dec 2025 |
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 |
emily | well select's ABI has no idea how big the fd_set is anyway | 00:46:06 |
emily | we are linking against the system select | 00:46:16 |
emily | admittedly it'd be an ABI break for fd_set not beind a pointer although I'm not sure if POSIX even guarantees that fd_set has a known size… | 00:46:56 |
emily | fwiw changing system ABI in cc-wrapper also means that everything that doesn't use a wrapper will potentially result in UB | 00:49:06 |
emily | e.g., libclang | 00:49:10 |
emily | stuff like hardening flags doesn't have that kind of effect | 00:49:40 |
Ihar Hrachyshka | The behaviour of these macros is undefined if the fd argument is less than 0 or greater than or equal to FD_SETSIZE.
Admittedly, there's nothing in POSIX that forces the value, but Apple decided to force it in libSystem. So maybe I should replace the wording that this could be related to POSIX certification with something better... | 00:50:01 |
Randy Eckenrode | The unwrapped case is a good argument not to do this by default, especially with more languages handling compilation themselves (e.g., Rust, Swift, Zig). | 00:51:13 |
Randy Eckenrode | * | 00:51:26 |
Ihar Hrachyshka | ack. are we ok with glib local change? | 00:51:53 |
emily | fwiw it looks like the flag actually redirects select to a variant with a different suffix | 00:52:12 |
emily | non-pointer fd_set ABI would still be an issue though (for both Apple and us) | 00:52:29 |
emily | let's see what upstream says? hopefully it can get merged there and we can just backport it | 00:53:11 |
emily | I'm wondering if glib could just do the heap allocation thing, but I guess that would be more major surgery | 00:53:20 |
emily | I'm a bit worried about the scope of glib_conf | 00:53:33 |
Ihar Hrachyshka | it's on stack atm. | 00:53:36 |
emily | e.g. is it set just for glib sources or for the sources of all programs that use glib? | 00:53:40 |
Ihar Hrachyshka | afaiu this is for building glib. | 00:53:56 |
Ihar Hrachyshka | (not for dependencies) | 00:54:16 |
Ihar Hrachyshka | * (not for children users) | 00:54:23 |
emily | https://gitlab.gnome.org/GNOME/glib/-/blob/2f8a985d6f603257707f1805713c42df72532a01/glib/gtypes.h does #include <glibconfig.h> | 00:54:33 |
emily | (and is included by other public glib headers) | 00:54:46 |
Ihar Hrachyshka | glibconfig.h ! config.h? | 00:54:54 |
Randy Eckenrode | Is it possible to add a test? Like try to have g_pol work with a large number of fds? Would that be an okay test? | 00:54:57 |