Stream: t-lang/wg-unsafe-code-guidelines

Topic: should valid fn be callable ?


gnzlbg (Jan 03 2019 at 18:23, on Zulip):

what is the gain from this requirement?

AFAICT that allows us to make the function pointer dereferenceable.

gnzlbg (Jan 03 2019 at 18:27, on Zulip):

i don't know if that impacts any optimizations

nikomatsakis (Jan 03 2019 at 18:32, on Zulip):

right

nikomatsakis (Jan 03 2019 at 18:33, on Zulip):

presuming that's even a valid LLVM attribute to apply to such a type

gnzlbg (Jan 03 2019 at 18:41, on Zulip):

right ! So dereferenceable(n) tells LLVM that n bytes are dereferenceable through the pointer, does that make sense for function pointers ? they don't "load" or "write" to bytes, but jump to the address instead.

nikomatsakis (Jan 03 2019 at 18:42, on Zulip):

right, this is what @RalfJ was saying -- it's not like we're going to insert "extra" calls to functions

gnzlbg (Jan 03 2019 at 18:42, on Zulip):

the requirement that the fn() pointer must be nonnull is already enough for that AFAICT, so this might not buy us anything

gnzlbg (Jan 03 2019 at 18:42, on Zulip):

ah, I didn't understood that part before

nikomatsakis (Jan 03 2019 at 18:43, on Zulip):

(in contrast to pointers, where there may be value in doing a load earlier even if it wouldn't have happened before)

nikomatsakis (Jan 03 2019 at 18:43, on Zulip):

e.g. to pull it out of a loop or something

Ariel Ben-Yehuda (Jan 03 2019 at 19:59, on Zulip):

I don't want to get into what it means for an fn being "callable"

RalfJ (Jan 04 2019 at 10:45, on Zulip):

the requirement that the fn() pointer must be nonnull is already enough for that AFAICT, so this might not buy us anything

exactly

Last update: Nov 19 2019 at 18:35UTC