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

Topic: meeting-2019-01-03


nikomatsakis (Jan 03 2019 at 15:06, on Zulip):

Do we plan to meet today, @WG-unsafe-code-guidelines ?

nikomatsakis (Jan 03 2019 at 15:06, on Zulip):

we have a calendar invite :)

gnzlbg (Jan 03 2019 at 15:07, on Zulip):

i'll be here

Alan Jeffrey (Jan 03 2019 at 15:08, on Zulip):

I'm around.

RalfJ (Jan 03 2019 at 15:39, on Zulip):

me too

RalfJ (Jan 03 2019 at 16:21, on Zulip):

so, what do we have to talk about?

RalfJ (Jan 03 2019 at 16:21, on Zulip):

@WG-unsafe-code-guidelines

gnzlbg (Jan 03 2019 at 16:22, on Zulip):

we should merge the enum repr PR, or figure out if anything is blocking the merge

RalfJ (Jan 03 2019 at 16:22, on Zulip):

I guess the PRs are a good place to start, yeah

RalfJ (Jan 03 2019 at 16:22, on Zulip):

@gnzlbg I am confused by what you said in your last comment there, why do you say the enum opt is not guaranteed to happen?

RalfJ (Jan 03 2019 at 16:22, on Zulip):

just because it is not normative?

RalfJ (Jan 03 2019 at 16:22, on Zulip):

the text otherwise seems pretty clear about it happening

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

yes, that's pretty much it

RalfJ (Jan 03 2019 at 16:23, on Zulip):

and the "not normative" just means "no RFC has happened yet", which is true and not something this document can change

nikomatsakis (Jan 03 2019 at 16:23, on Zulip):

:wave: sorry was late

nikomatsakis (Jan 03 2019 at 16:24, on Zulip):

but @RalfJ is asking the question I was in the midst of asking :)

gnzlbg (Jan 03 2019 at 16:24, on Zulip):

we have identified that an RFC in this direction might be useful, we don't have to make that RFC part of the UCG, but it is probably worth it to raise that issue somewhere

nikomatsakis (Jan 03 2019 at 16:24, on Zulip):

(one related question : should we maybe keep a place to list out things we think ought to be RFC'd?)

nikomatsakis (Jan 03 2019 at 16:24, on Zulip):

my general plan @gnzlbg is for these documents to become RFCs once we've gotten enough of a "coherent whole"

RalfJ (Jan 03 2019 at 16:25, on Zulip):

we could have issues for that, and a tag to collect them? like, one issue per to-be-RFC?

nikomatsakis (Jan 03 2019 at 16:25, on Zulip):

but maybe it's worth trying to catalog the bits so we can decide how to carve those up

nikomatsakis (Jan 03 2019 at 16:25, on Zulip):

we could use issues

nikomatsakis (Jan 03 2019 at 16:25, on Zulip):

seems like a fine place to start

nikomatsakis (Jan 03 2019 at 16:25, on Zulip):

although I think maybe it belongs rather in the text

gnzlbg (Jan 03 2019 at 16:25, on Zulip):

i think issues are fine, my point was only that we should write those down somewhere

nikomatsakis (Jan 03 2019 at 16:25, on Zulip):

(i.e., all the things we plan to "RFC" ought to be written in the text in some place in a "non-normative" fashion, so maybe we should maintain the list using PRs)

RalfJ (Jan 03 2019 at 16:25, on Zulip):

another point is that most of the stuff in "reference" needs an RFC

RalfJ (Jan 03 2019 at 16:26, on Zulip):

I mean there's no RFC saying union fields have offset 0

RalfJ (Jan 03 2019 at 16:26, on Zulip):

and while there's no other choice, it might still be worth RFC-ing

nikomatsakis (Jan 03 2019 at 16:26, on Zulip):

yes, so some part of me feels like we should just do a sweep afterwards

nikomatsakis (Jan 03 2019 at 16:26, on Zulip):

since it's kind of "everything"

gnzlbg (Jan 03 2019 at 16:26, on Zulip):

I think a lot of these issues are going to be part of the first UCG RFC

RalfJ (Jan 03 2019 at 16:26, on Zulip):

so are we going to have an UCG WG RFC PR? need moar acronyms :P

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

but maybe it might be worth it to put some of these on independent RFCs, some of which could be happening already (e.g. Option-like layout optimizations)

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

IIRC eddyb was interested in guaranteeing some of the enum optimizations that enough code is already relying on

RalfJ (Jan 03 2019 at 16:27, on Zulip):

yeah

RalfJ (Jan 03 2019 at 16:28, on Zulip):

okay so let's merge this one then?

nikomatsakis (Jan 03 2019 at 16:28, on Zulip):

it seems better to carve out independent questions where we can

gnzlbg (Jan 03 2019 at 16:28, on Zulip):

and lets open an issue or add a document with a list of things that should be RFC'ed somewhere ?

nikomatsakis (Jan 03 2019 at 16:28, on Zulip):

I am :+1: on merging for now, and I think we should make a list of potential RFCs -- I am happy to make it an issue for now, I guess, though I think maybe it would be a nice part of the document

RalfJ (Jan 03 2019 at 16:29, on Zulip):

anything that gives us a good list that we all can add items to

nikomatsakis (Jan 03 2019 at 16:29, on Zulip):

I feel like there could be a section basically listing out the justifications for each part

RalfJ (Jan 03 2019 at 16:29, on Zulip):

justifications?

nikomatsakis (Jan 03 2019 at 16:29, on Zulip):

(that is, RFC that justify declaring this to be true)

nikomatsakis (Jan 03 2019 at 16:29, on Zulip):

I'll open issues for now I guess, seems fine

RalfJ (Jan 03 2019 at 16:30, on Zulip):

ah, yes

gnzlbg (Jan 03 2019 at 16:30, on Zulip):

so other open PRs ready to merge ?

RalfJ (Jan 03 2019 at 16:30, on Zulip):

the function ptr PR is waiting on @Nicole Mazzuca

RalfJ (Jan 03 2019 at 16:30, on Zulip):

what about https://github.com/rust-rfcs/unsafe-code-guidelines/pull/58 ?

nikomatsakis (Jan 03 2019 at 16:31, on Zulip):

the function ptr PR is waiting on @Nicole Mazzuca

this is https://github.com/rust-rfcs/unsafe-code-guidelines/pull/45, for reference

nikomatsakis (Jan 03 2019 at 16:31, on Zulip):

I think the only thing are a few nits? I can take a stab at making this perhaps

nikomatsakis (Jan 03 2019 at 16:31, on Zulip):

I'd like to move it to fcp

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

what about https://github.com/rust-rfcs/unsafe-code-guidelines/pull/58 ?

I think this is good, let's merge

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

(I feel like we reached agreement on that the last time, right?)

gnzlbg (Jan 03 2019 at 16:32, on Zulip):

sounds good, @Nicole Mazzuca wanted to fix the nits, but I'd guess holidays happened

Nicole Mazzuca (Jan 03 2019 at 16:32, on Zulip):

yeah lol

Nicole Mazzuca (Jan 03 2019 at 16:32, on Zulip):

sorry

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

I'm also game to wait :) just want to keep things moving, seems like a rote task.

RalfJ (Jan 03 2019 at 16:33, on Zulip):

okay @nikomatsakis and @Nicole Mazzuca can coordinate about finishing that one :)

RalfJ (Jan 03 2019 at 16:33, on Zulip):

what about https://github.com/rust-rfcs/unsafe-code-guidelines/pull/59 ?

gnzlbg (Jan 03 2019 at 16:33, on Zulip):

@nikomatsakis about https://github.com/rust-rfcs/unsafe-code-guidelines/pull/58 - i wish we would just use layout in the document, but we probably need to use representation at least when explaining what repr stands for

RalfJ (Jan 03 2019 at 16:34, on Zulip):

@gnzlbg the thing is we use representation everywhere, so I documented the de-facto state

RalfJ (Jan 03 2019 at 16:34, on Zulip):

I am open to just using layout everywhere, but then we'll have to rename some files

RalfJ (Jan 03 2019 at 16:34, on Zulip):

do you want to open an issue?

gnzlbg (Jan 03 2019 at 16:34, on Zulip):

I can do that

gnzlbg (Jan 03 2019 at 16:35, on Zulip):

About #59 i think it might make sense to make those changes together with the StackedBorrow changes, but I haven't read the StackedBorrow PR yet

nikomatsakis (Jan 03 2019 at 16:35, on Zulip):

what about https://github.com/rust-rfcs/unsafe-code-guidelines/pull/59 ?

I feel fine with the text, apart from the nit that this all sounds like the definition of "interior mutation" to me (versus "interior mutability")

nikomatsakis (Jan 03 2019 at 16:35, on Zulip):

to me, interior "mutability" is all about UnsafeCell -- that is, the declared potential for such mutation

gnzlbg (Jan 03 2019 at 16:35, on Zulip):

But #59 is how miri already works in nightly, so I'm fine with doing that change now, maybe we can move it to FCP ?

nikomatsakis (Jan 03 2019 at 16:35, on Zulip):

(but I can leave those comments in the PR)

gnzlbg (Jan 03 2019 at 16:36, on Zulip):

I somehow have the feeling that the PRs that happened right before christmas haven't received much attention, so I'd prefer to hold down on them a little

RalfJ (Jan 03 2019 at 16:36, on Zulip):

to me, interior "mutability" is all about UnsafeCell -- that is, the declared potential for such mutation

I can reword things a bit following that

RalfJ (Jan 03 2019 at 16:37, on Zulip):

we can leave it open another week, I don't care shrug

nikomatsakis (Jan 03 2019 at 16:37, on Zulip):

I am open to just using layout everywhere, but then we'll have to rename some files

I wonder if we should use representation everywhere instead? Or maybe it's useful to use representation to refer only to the #[repr] attributes themselves (ie., the user specifies the "representation" (C, Rust, etc) which then affects the resulting layout)

nikomatsakis (Jan 03 2019 at 16:37, on Zulip):

not sure if I would make too much of that distinction, since the two words seem like synonyms, but it seems like a convention we could try to adhere to

nikomatsakis (Jan 03 2019 at 16:38, on Zulip):

otoh I sort of prefer something like "#[repr] attribute", since it is so concrete

nikomatsakis (Jan 03 2019 at 16:38, on Zulip):

so never mind :)

RalfJ (Jan 03 2019 at 16:38, on Zulip):

I don't really understand the distinction, given that it seems entirley reasonable to imagine a #[repr(_)] that manually specifies all layout details

nikomatsakis (Jan 03 2019 at 16:39, on Zulip):

I'm not sure why that would matter. The distinction was basically "what did the user write" versus "what is the effect of that" -- but I prefer to say #[repr] for the former.

RalfJ (Jan 03 2019 at 16:39, on Zulip):

yeah seems wasteful and confusing to have totally different terms for syntax and semantics

nikomatsakis (Jan 03 2019 at 16:39, on Zulip):

e.g., you could imagine writing

When an enum has C representation...

vs

When an enum is declared #[repr(C)]...

RalfJ (Jan 03 2019 at 16:39, on Zulip):

though it is somewhat unfortunate that the attribute is not #[layout]

nikomatsakis (Jan 03 2019 at 16:40, on Zulip):

but the latter feels far more clear

nikomatsakis (Jan 03 2019 at 16:40, on Zulip):

though it is somewhat unfortunate that the attribute is not #[layout]

yes, so, one could imagine centralizing on the representation instead

nikomatsakis (Jan 03 2019 at 16:40, on Zulip):

the compiler's "layout" notwithstanding

RalfJ (Jan 03 2019 at 16:40, on Zulip):

well then we have a mismatch with the compiler

nikomatsakis (Jan 03 2019 at 16:40, on Zulip):

the compiler data structures can be renamed

RalfJ (Jan 03 2019 at 16:40, on Zulip):

and also what I wrote about "representation" in the PR

RalfJ (Jan 03 2019 at 16:41, on Zulip):

And @ubsan has some other ideas for what "representation" can mean: When relating mathematical values to objects in memory, a "representation" defines how mathematical objects map to bitstrings.

nikomatsakis (Jan 03 2019 at 16:41, on Zulip):

(but I'm fine with just saying we use the terms interchangeably as well)

RalfJ (Jan 03 2019 at 16:41, on Zulip):

this is a common term when doing reasoning about programs

nikomatsakis (Jan 03 2019 at 16:41, on Zulip):

ah, yes, I remembered that there was a contested term, but I forgot which it was

nikomatsakis (Jan 03 2019 at 16:41, on Zulip):

yes, true.

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

if we centralize on _representation_ then we need a different word for relating mathematical objects to bitstrings

nikomatsakis (Jan 03 2019 at 16:41, on Zulip):

layout seems fine. who cares what the attribute says.

RalfJ (Jan 03 2019 at 16:41, on Zulip):

^^

RalfJ (Jan 03 2019 at 16:42, on Zulip):

for my other two PRs (the optimization and Stacked Borrows) I guess the only question at this point is whether this repo is the right place for this text

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

but I guess that means that the use of "representation" as a synonym is basically "deprecated"

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

for my other two PRs (the optimization and Stacked Borrows) I guess the only question at this point is whether this repo is the right place for this text

in the case of stacked borrows, at least, I think it is

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

suitably caveated

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

we can just change everything to use layout, except for repr, and maybe some day add layout as a synonym for repr and deprecate repr instead

RalfJ (Jan 03 2019 at 16:43, on Zulip):

it's in a "wip" directory currently, because I am not very creative

gnzlbg (Jan 03 2019 at 16:43, on Zulip):

although we don't have to do it, we can just say that repr controls layout and that's it

nikomatsakis (Jan 03 2019 at 16:44, on Zulip):

re: stacked borrows, I feel like once we finish up with "validity invariants", it'll probably be a topic we start to discuss more broadly, hence the reason it belongs

nikomatsakis (Jan 03 2019 at 16:44, on Zulip):

I am fine with wip as a directory name:)

RalfJ (Jan 03 2019 at 16:45, on Zulip):

speaking of which, when can we officially transition to "validity invariants"?^^

nikomatsakis (Jan 03 2019 at 16:47, on Zulip):

I was going to raise that

nikomatsakis (Jan 03 2019 at 16:47, on Zulip):

we should do it I think

Nicole Mazzuca (Jan 03 2019 at 16:47, on Zulip):

hmm, is it reasonable to be able to write:

fn foo(x: fn(), y: DynamicLibrary) { // assume x ∈ y
  x();
  drop(y);
}
nikomatsakis (Jan 03 2019 at 16:47, on Zulip):

strictly speaking, we already merged https://github.com/rust-rfcs/unsafe-code-guidelines/pull/54...

nikomatsakis (Jan 03 2019 at 16:48, on Zulip):

...so what is needed to "officially transition"? Shift some labels and make an announcement, I guess?

nikomatsakis (Jan 03 2019 at 16:48, on Zulip):

Open the issues in question?

RalfJ (Jan 03 2019 at 16:48, on Zulip):

Open the issues in question?

that at least

RalfJ (Jan 03 2019 at 16:48, on Zulip):

otherwise, no idea^^

RalfJ (Jan 03 2019 at 16:49, on Zulip):

@Nicole Mazzuca where drop does unmap or so? ugh...

nikomatsakis (Jan 03 2019 at 16:49, on Zulip):

hmm, is it reasonable to be able to write:

given that fn pointers don't have lifetimes, I think we effectively ruled out the option of using them in this way, at least in safe code.

nikomatsakis (Jan 03 2019 at 16:49, on Zulip):

we did debate about giving them lifetimes to enable that pattern

Nicole Mazzuca (Jan 03 2019 at 16:49, on Zulip):

@nikomatsakis I'm not saying it's safe

nikomatsakis (Jan 03 2019 at 16:49, on Zulip):

but it was late in the 1.0 process and we kind of bailed on it

Nicole Mazzuca (Jan 03 2019 at 16:49, on Zulip):

just valid

nikomatsakis (Jan 03 2019 at 16:49, on Zulip):

well, then it seems like a stacked borrows question to me :)

RalfJ (Jan 03 2019 at 16:49, on Zulip):

well this is not about returning the fn() to outside code... what @Nicole Mazzuca said

RalfJ (Jan 03 2019 at 16:49, on Zulip):

hm no there's no memory access

RalfJ (Jan 03 2019 at 16:49, on Zulip):

it's a validity invariant question

nikomatsakis (Jan 03 2019 at 16:50, on Zulip):

you are accessing memory

nikomatsakis (Jan 03 2019 at 16:50, on Zulip):

the PC is changing

nikomatsakis (Jan 03 2019 at 16:50, on Zulip):

and the processor is loading the instruction at that new address

RalfJ (Jan 03 2019 at 16:50, on Zulip):

do fn ptrs have to point to dereferencable code memory, or so?

nikomatsakis (Jan 03 2019 at 16:50, on Zulip):

that is basically the question, right?

RalfJ (Jan 03 2019 at 16:50, on Zulip):

but x isn't used again after the drop

gnzlbg (Jan 03 2019 at 16:50, on Zulip):

@RalfJ could you open the issues for the validity discussions and tag them appropriately ?

Nicole Mazzuca (Jan 03 2019 at 16:50, on Zulip):

like, it seems unreasonable to not allow this, given that I think it basically means hot loading becomes UB

RalfJ (Jan 03 2019 at 16:50, on Zulip):

@Nicole Mazzuca only hot unloading

nikomatsakis (Jan 03 2019 at 16:50, on Zulip):

but x isn't used again after the drop

basically I'm saying it comes down to a question of whether there are barriers

RalfJ (Jan 03 2019 at 16:51, on Zulip):

for &T we say "must be derefencable", do we have something similar for fn()?

RalfJ (Jan 03 2019 at 16:51, on Zulip):

there's no &, no lifetime, and also no size. so no barrier.

nikomatsakis (Jan 03 2019 at 16:51, on Zulip):

at least I think fn pointers would likely have some similar modeling. I suspect it would we can craft the rules to make it ok or not as we choose.

Nicole Mazzuca (Jan 03 2019 at 16:51, on Zulip):

@RalfJ sure

nikomatsakis (Jan 03 2019 at 16:51, on Zulip):

(I also think it's ok for it to be valid in unsafe code)

RalfJ (Jan 03 2019 at 16:51, on Zulip):

fn() doesnt point to X bytes of data

gnzlbg (Jan 03 2019 at 16:51, on Zulip):

Can the x() be re-ordered after the drop(y) ?

nikomatsakis (Jan 03 2019 at 16:52, on Zulip):

at least not where X is statically known

Nicole Mazzuca (Jan 03 2019 at 16:52, on Zulip):

also my cat is running around and just jumped over my computer, and locked it

Nicole Mazzuca (Jan 03 2019 at 16:52, on Zulip):

I just thought that was cute

RalfJ (Jan 03 2019 at 16:52, on Zulip):

X is not dynamically determinable either

nikomatsakis (Jan 03 2019 at 16:52, on Zulip):

well, the compiler knows

nikomatsakis (Jan 03 2019 at 16:52, on Zulip):

but anyway not imporant

nikomatsakis (Jan 03 2019 at 16:52, on Zulip):

I think we all agree it should be ok, right?

Nicole Mazzuca (Jan 03 2019 at 16:52, on Zulip):

yeah

RalfJ (Jan 03 2019 at 16:53, on Zulip):

I am not sure

nikomatsakis (Jan 03 2019 at 16:53, on Zulip):

i.e., I think that we'll have to be sure that future models respect it, as @Nicole Mazzuca noted it seems like it'd be needed in implementing wrappers around dynamic linking

Nicole Mazzuca (Jan 03 2019 at 16:53, on Zulip):

I don't see a reasonable optimization you can do, given that <DynamicLibrary as Drop>::drop is not a pure function

nikomatsakis (Jan 03 2019 at 16:53, on Zulip):

or at least it'd be good to know if there are LLVM opts or other things that would interfere

RalfJ (Jan 03 2019 at 16:53, on Zulip):

I always though fn ptrs must at least point to some allocated memory

RalfJ (Jan 03 2019 at 16:53, on Zulip):

but I also didnt think that would exclude anything reasonable

nikomatsakis (Jan 03 2019 at 16:53, on Zulip):

seems like a validity invariant question, regardless

RalfJ (Jan 03 2019 at 16:53, on Zulip):

and I doubt we'll want to allow the compiler to insert spurious calls to fn ptrs :P

nikomatsakis (Jan 03 2019 at 16:53, on Zulip):

so, coming back to that topic of when to shift :)

nikomatsakis (Jan 03 2019 at 16:54, on Zulip):

I propose we...just do it

RalfJ (Jan 03 2019 at 16:54, on Zulip):

so yeah, this just means that fn ptr validity is even weaker than I thought. it's basically just "not NULL". seems fine.

Nicole Mazzuca (Jan 03 2019 at 16:54, on Zulip):

alright, I'll write it down as a safety invariant but not a validity invariant

RalfJ (Jan 03 2019 at 16:54, on Zulip):

safety invariant is clearly "can be called safely (meaning without causing UB) with safe arguments and will return safe result"

RalfJ (Jan 03 2019 at 16:54, on Zulip):

but we wont be able to check that in Miri any time soon :P

Nicole Mazzuca (Jan 03 2019 at 16:55, on Zulip):

cools

RalfJ (Jan 03 2019 at 16:55, on Zulip):

but we didn't specify any safety invariant anywhere I think? it's also quite hard to do so without a full-fledged program logic...

nikomatsakis (Jan 03 2019 at 16:56, on Zulip):

I think it's worth stating informally

nikomatsakis (Jan 03 2019 at 16:56, on Zulip):

we should prob go back at some point

RalfJ (Jan 03 2019 at 16:56, on Zulip):

but I guess it makes sense to have approximations where we can, yeah

nikomatsakis (Jan 03 2019 at 16:56, on Zulip):

but it'd be nice to sort of write things like "if you are returning a value of type T to safe code, here is what you have to ensure"

nikomatsakis (Jan 03 2019 at 16:56, on Zulip):

..."and here are some common pitfalls" :)

RalfJ (Jan 03 2019 at 16:56, on Zulip):

"prove the following thing in Coq" :P

nikomatsakis (Jan 03 2019 at 16:56, on Zulip):

lol

RalfJ (Jan 03 2019 at 16:57, on Zulip):

anyway I got to go, ttyl!

nikomatsakis (Jan 03 2019 at 16:57, on Zulip):

so I guess I will .. just switch the active area

nikomatsakis (Jan 03 2019 at 16:57, on Zulip):

I'll figure out what that means but I think it's mostly opening some issues?

RalfJ (Jan 03 2019 at 16:57, on Zulip):

yes please :) I can help opening issues over the weekend

nikomatsakis (Jan 03 2019 at 16:57, on Zulip):

great

RalfJ (Jan 03 2019 at 16:57, on Zulip):

and probably tmr though I probabloy shouldnt...^^

nikomatsakis (Jan 03 2019 at 16:57, on Zulip):

:)

nikomatsakis (Jan 03 2019 at 16:57, on Zulip):

:wave: thanks all

nikomatsakis (Jan 03 2019 at 16:57, on Zulip):

I gotta go too

gnzlbg (Jan 03 2019 at 16:57, on Zulip):

i won't be here next week

Nicole Mazzuca (Jan 03 2019 at 16:57, on Zulip):

alright, committed and pushed the changes

gnzlbg (Jan 03 2019 at 16:58, on Zulip):

issue about using layout consistently has been opened

gnzlbg (Jan 03 2019 at 16:58, on Zulip):

i can a PR to do those changes later

gnzlbg (Jan 03 2019 at 16:59, on Zulip):

so why can't function pointer validity require that they point to a valid function ?

gnzlbg (Jan 03 2019 at 16:59, on Zulip):

can someone do a TL;DR ?

Nicole Mazzuca (Jan 03 2019 at 17:00, on Zulip):

@gnzlbg requiring function pointers to point to a valid function would, imo, break dynamic loading

Nicole Mazzuca (Jan 03 2019 at 17:00, on Zulip):

(assuming you want to be able to dynamically unload as well)

gnzlbg (Jan 03 2019 at 17:00, on Zulip):

I'd expect @Nicole Mazzuca 's example to be UB, calling dropto unload functions is fine as long as there are no function pointers referring to those functions

gnzlbg (Jan 03 2019 at 17:01, on Zulip):

that's not the case there, so that would be UB

gnzlbg (Jan 03 2019 at 17:01, on Zulip):

but if you write a wrapper over a dynamic library, and control all your fn pointers somehow (e.g. reference count them), then it should be fine to drop the library if all pointers are dead

Nicole Mazzuca (Jan 03 2019 at 17:07, on Zulip):

@gnzlbg I don't think that's reasonable, tbh

Nicole Mazzuca (Jan 03 2019 at 17:07, on Zulip):

for unsafe code in specific

Nicole Mazzuca (Jan 03 2019 at 17:07, on Zulip):

and, especially since I can't see a reasonable way to observe this through optimization

gnzlbg (Jan 03 2019 at 17:08, on Zulip):

I mean, if one is doing dynamic hot loading, chances are that one is already using Option<fn()> everywhere for that

nagisa (Jan 03 2019 at 17:09, on Zulip):

there are more issues with dynamic unloading anyway

nagisa (Jan 03 2019 at 17:09, on Zulip):

e.g. 'static does not work at all...

nagisa (Jan 03 2019 at 17:09, on Zulip):

Got an fn foo() -> &'static str? Well, you’re screwed if that str happens to be in an unloadable module...

Nicole Mazzuca (Jan 03 2019 at 17:17, on Zulip):

@nagisa yes

Nicole Mazzuca (Jan 03 2019 at 17:17, on Zulip):

that does not mean dynamic unloading isn't useful

avadacatavra (Jan 03 2019 at 17:17, on Zulip):

oh hello friends--hope you had a happy new year

avadacatavra (Jan 03 2019 at 17:17, on Zulip):

/me just woke up from an unexpected work nap

Nicole Mazzuca (Jan 03 2019 at 17:17, on Zulip):

and it does not mean we should disallow it

avadacatavra (Jan 03 2019 at 17:17, on Zulip):

cc @RalfJ @nikomatsakis

Alan Jeffrey (Jan 03 2019 at 17:26, on Zulip):

Just back from a last-minute meeting about something else, looks like you survived without me :smile:

nikomatsakis (Jan 03 2019 at 17:27, on Zulip):

/me just woke up from an unexpected work nap

good day =)

nikomatsakis (Jan 03 2019 at 17:27, on Zulip):

and yes, happy new year! :tada:

nikomatsakis (Jan 03 2019 at 17:27, on Zulip):

:fireworks:

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

@Nicole Mazzuca requiring valid fn()s to be callable doesn't make unloading impossible

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

one just needs to be more careful about how to construct fns from hot loaded libraries and when those libraries can actually be unloaded, but it appears that one already has to be very careful here any ways

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

what is the gain from this requirement?

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

I'd like to hear that question answered

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

also, we should probably break this out into a separate topic

Last update: Nov 19 2019 at 18:50UTC