Validity of function pointers

[RalfJung]

Discussing the validity of function pointers.

Clearly, the must be non-NULL. Since we exclude some bit patterns, we likely also do not want to allow the entire value to be uninitialized. We could allow some bits to be uninitialized as long as there is at least one bit initialized to 1, but, uh, why?^^

Anything else? Do fn ptrs have to point to allocated executable memory? This discussion concludes that the answer ought to be "no", because there's little to no benefit and it would interact badly with unloading shared libraries.

[nikomatsakis]

I think we should not require that they point to allocated, executable memory and we should forbid NULL, but otherwise permit any initialized value. As you say, I don't see much value to permitting some bits to be uninitialized.

[RalfJung]

I recently learned that function pointers could, in principle, have alignment requirements. However, currently the alignment seems to be 1 for all supported platforms. The fn docs call out the non-NULL property as does the Nomicon, but they do not call out alignment. Miri also does not check fn ptr alignment as it has no good way to figure out what the requirements for that are, and anway it currently would not do anything.

So should those docs be amended to call out the alignment situation? Which place should they point at if someone wants to figure out the fn ptr alignment for their platform? There is no such thing as align_of for this.

Also, should https://doc.rust-lang.org/reference/types/function-pointer.html or https://doc.rust-lang.org/book/ch19-05-advanced-functions-and-closures.html call out the non-NULL property and/or the alignment?

[hanna-kruppe]

I don't think we should put any alignment requirement into the validity invariant. LLVM having this notion is no reason to -- in fact, the function pointer alignment patch fixed a wrong assumption made by LLVM's optimizations about what happens when you take a pointer to a known function. Trying to establish alignment requirements for arbitrary pointers to unknown functions would go far beyond that and is too much headache for too little reward:

• In terms of instruction alignment required by the hardware, there's often not much alignment to be had: at most 2 bytes on pretty much every ISA that doesn't have horrible code density, and not even that on e.g. x86(-64).
  • Sometimes we can't even exploit the instruction alignment the hardware does require, e.g. ARM hardware uses the LSB of function pointers to indicate a switch to Thumb mode, so their LSB can be set even though the function it points to is aligned to 2 bytes or more.
  • The instruction alignment requirement can be lowered by later extensions that are intended to be backwards compatible (e.g., for RISC-V, it's normally 4, but once the C extension is added it can become 2).
• Even if the platform ABI prescribes that functions are to be aligned to such-and-such, it's perfectly possible to generate a symbol that goes below this threshold, and it would be really annoying if that would cause subtle UB in Rust code that handles a pointer to that function.

[hanna-kruppe]

Oh, and all of this is assuming we're only interested in allowing legitimate pointers to actual functions you can jump to. It's potentially useful if one can just smuggled arbitrary non-null addresses through a function pointer that is never called. It's certainly less of a footgun. People are already being bitten relatively frequently by function pointers being non-null, making the niche larger can only make that (marginally) worse.

[RalfJung]

I don't think we should put any alignment requirement into the validity invariant.

That's fine for me as long as LLVM does the same.

[hanna-kruppe]

Function pointers aren't really different from other pointers (in fact, they'll be literally indistinguishable once the long-awaited untyped ptr arrives). And alignment of pointers is only asserted if you do something with them (e.g., dereference or, in this case, call) or explicitly put in an assume call, align attribute, etc. into the IR.

[RalfJung]

I see. So I guess what I mean is "as long as we don't add any assume or align".

[RalfJung]

Also see this discussion. Currently at least docs would have to keep open the possibility that function pointers have to be aligned to "something" in the future. OTOH, I feel adding something like that at rust-lang/nomicon#149 would not be very useful, as we couldn't even define the "something".

Would it be worth trying to write a (small) RFC that basically just says "for function pointers, NULL is and will be the only invalid value"? Just to get that out of the way?

[Lokathor]

I'd like an RFC to that effect, and, because it's such a simple statement, I'd like that to be considered for entry into the proposed "normative statements about Rust list" that the Reference can hopefully begin to grow (rust-lang/reference#629).