Today work has focused entirely on the sighandler_t issue that I started to work on
yesterday.
Thus far, I’ve been finishing up my notes, and reading through the relevant Zulip threads where discussion took place recently surrounding matters related to raw function pointers.
From my read on the comments there, nothing mentioned will help us solve the issue. Neither will the proposal by T-libs that I didn’t get the chance to read yesterday. I’ll start with the latter and then summarize the former.
The T-libs proposal attempts to have a more explicit way with which to fetch the address of a function pointer,
which happens to currently require use of the as
operator. This causes some subtle confusions when, say, a function identifier happens to have a very similar name in
source to that of a constant item with an integer value.
The end goal, though, is not to allow for function pointers to be built from null values; That continues being a
strict immediate UB in all cases, as invalid function pointers are allowed (unless “used”) with any transmutations
but those that would yield a null pointer (e.g. 0; Our exact usecase.)
The Zulip threads started off by commenting on how can downstream Rust users more clearly know whether a function item or a function pointer is being fetched (based off of mostly purely syntactic aspects.) The former yields a useless address, while the latter will provide an actual address to the start of the function’s code.
Most comments, though, seem to be around the fact that &fn() would
possibly make function pointers that are guaranteed to be valid or non-null (like the only ones we have today) more
meaningful, while a different type could be used for “raw function pointers.”
That seemed to be going somewhere until it derailed into a different discussion about &fn() possibly
conveying what a function pointer really is, while simply fn type() could be
used for referring to function items. Then they started discussion on some subtleties around lifetime subtyping
between the types contained in another type, and from that point on, there’s been nothing new since July 3rd, 2026.
None of this ever mentioned the possibility for raw function pointers to hold a possibly null value except for the last comment on the original thread (as the derailed discussion got moved to another thread.) That one comment (by my mentor) didn’t receive more feedback when it came to the raw function pointer stuff, though.
With this, I took some further notes, and started thinking (and taking more notes) about the design that my mentor
proposed in the tracking issue in rust-lang/libc. There they present the use of a custom type that holds either
nothing or a function pointer (through a sealed trait that would be implemented only for unsafe extern function pointers.)
I’ve iterated some more on this, both trying out to see how that would work with an inlined generic type that
implemented this sealed trait, within an untagged union that would also consider a “raw” variant for integers such
as 0.
Thus far, that would mean that the approach that was put on halt a few months ago (using a three-variant union) will likely end up being the short-term solution.
None.
I don’t think it will take me more than two to three days to have my thoughts ready and something to show in the tracking issue. That will already happen outside GSoC, though, but I plan on continuing these daily reports.
So if somebody is reading this, you can follow up at https://dybucc.github.io/daily-reports (once it’s set up.) Though it will contain information tangential to rust-lang/libc.
It may just be that it takes less than 2 days and I’m done tomorrow, but I’d rather be cautious when estimating dates.