| 29 Dec 2025 |
 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 |
| Randy Eckenrode | * Is it possible to add a test? Like try to have g_poll work with a large number of fds? Would that be an okay test? | 00:55:19 |
| emily | hmm, though I have no glibconfig.h | 00:55:33 |
| Ihar Hrachyshka | https://github.com/GNOME/glib/blob/main/glib/glibconfig.h.in | 00:56:02 |
