Today work has focused solely on two things; Opening up the PR with the changes for Padding made
yesterday, and starting work on a new issue.
The first thing that I did was to open the PR that I didn’t have time to open yesterday. I ran the patch through CI one more time, just in case, but there didn’t seem to be any issues.
Then I went on to the 1.0 release milestone and picked up another issue. This time it’s concerned with
sigaction_t, which is a type often used through an untagged union of two function pointers, that also
happens to often be the target of a cast from integers to function pointers.
The underlying issue here is that both Unices and Windows have the same constants using this type; Namely, it’s not
immediate UB to merely construct one such function pointer out of integers, so long as it’s non-null. But both
target familites require there being a constant that casts 0 to one such function pointer, so the
current state of affairs is unsufficient.
I’ve started taking notes on the solutions attempted thus far, as well as the potential future direction that Rust is taking for, among other things, raw function pointers.
The first two solutions that were attempted consisted of simply replacing the type with a
*const c_void, and of defining it with a three-variant union that could hold the expected
function pointer variants and a third, “raw” integer variant.
The latter seems to be the more likely option to solve the issue in the short term, as it’s been the one receiving
the latest attention at rust-lang/libc. Granted, some further type infrastructure would be built around it to ensure
that the type is not misused without establishing an unsafe contract.
Another solution that I’ve yet to take notes on is a relatively recent ACP by T-libs. I’ve not yet read it, so I
can’t comment on it, but it was linked in both the Zulip threads that discussed the sigaction_t
matters, as well as the tracking issue in rust-lang/libc.
None.
I believe this issue will take some more time, and will quite definitely not fit withing GSoC 2026. It matters not. My plan is to implement the short-term solution to see whether there’s any issues discussion alone can’t reveal, and then see about the potentially more viable solution approved by T-libs.
Tomorrow I’ll just finish taking notes, organize them, and start looking into the first of the above two goals.