initial pass at function pointers

[strega-nil]

No description provided.

[RalfJung]

This should likely reference the enum chapter once one exists; I guess the rules here will be exactly the same as the ones for reference types?

[strega-nil]

Yep!

[nikomatsakis]

I'm not sure what it means to be 'static. If "T is 'static" means T: 'static, then this is not strictly true. For example,

fn(&'a u32): 'static

does not hold. This is fallout from the "syntactic definition of outlives". Such a type is not entirely trivial to make though.

I think the point is that fn pointer types do not carry their own lifetime, so they are always assumed to point to a statically defined function with no state of its own, right? Maybe we can word that more directly.

[RalfJung]

On Zulip, @ubsan was asking about function pointer transmutes:

Can you transmute<fn(*const T), fn(*const ())>(x)(p)?

(I assume we have T: Sized here.)

I would say we can modularize the problem (but this goes deep into validity invariant territory):

1. The actual cast is always okay, because the validity invariant for function pointers does not talk about the signature. Maybe it just says "non-NULL", maybe it also says "points to executable memory", but I think it should not take the signature into account.
2. The call, then, is when things may become UB if the signatures are wrong. We probably need some definition of "ABI compatible" here: Which "mismatches" we allow between the caller and callee signature will depend not just on layout but also on ABI concerns. For example, CTFE/miri currently say that either the type must be exactly the same, or else both types must have Scalar ABI that may differ only in its valid_range. In your example, the second condition is satisfied. If the mismatch is not allowed, we have UB.
3. The behavior of allowed argument mismatches, then, is the same as that of a transmute, of union-based type punning, and of type punning through changing pointer types: In your case, I would say your code is equivalent to x(mem::transmute<*const T, *const ()>(p)).

[hanna-kruppe]

The behavior of allowed argument mismatches, then, is the same as that of a transmute, of union-based type punning, and of type punning through changing pointer types: In your case, I would say your code is equivalent to x(mem::transmute<*const T, *const ()>(p)).

That doesn't work because type punning is just about in-memory representation (and notions that build on it, like validity) but here the call ABI matters as well. For example, one can easily transmute between integers and floats, but trying transmute<fn(f32) -> f32, fn(i32) -> i32>(f32::sin)(42) needs to be UB: on many targets the caller would pass the parameter in an integer register but the callee expects it in a floating point register.

[RalfJung]

here the call ABI matters as well.

That's why there is an ABI compat check first, declaring full UB unless the types are ABI-compatible "enough". The third point only comes to bear if the check in the second passes. (This is why I said "behavior of allowed mismatches", which I just added emphasis to.)

[hanna-kruppe]

Oops, don't know how I missed that 🤐

[RalfJung]

@ubsan will you have time to do another pass over this, incorporating comments, until our next meeting in two weeks?

[strega-nil]

@RalfJung yeah! I'll do it this weekend.

[nikomatsakis]

Things remaining to be done before merging:

• Address the question of 'static raised here
• Open an issue on the topic of "when can fn pointers be transmured" and copy over and/or link to Ralf's comment here
  • we can reference the issue in the text

[RalfJung]

I'd just say something like: "Function pointers have no lifetime. They must point to an allocated block of code when being called."

The rest of this belongs to #72, doesn't it?

[RalfJung]

Open an issue on the topic of "when can fn pointers be transmured"

Done: #81

[vi]

Is the lack of #[repr(C)] accidental or intentional?

[Lokathor]

probably accidental, however you should probably open a new issue about this, because a years old PR is a little too out of the way to get much attention.

[vi]

Shall I stop using this algorithm (spot suspicious place in a git-based book -> go to repo -> go to that file -> blame -> comment) in general?

Github UI seems to provide nice way of attaching comments to specific lines in files, so I expected those comments would be delivered precisely to those who deal with that particular file.

[Lokathor]

Well as I said this PR is years old. The person who wrote it doesn't even really work on Rust any more.

We are happy to have people taking an interest in fixing anything amiss, it's just that a new issue is generally preferred over continued discussion on a merged or closed PR, particularly an older one. That way the question and/or comment will stay on the list of things to resolve rather than be potentially forgotten by accident. Many people working on Rust have so many watched issues and projects that individual notifications/emails can easily get lost among them all.