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

Topic: Meeting 2019-08-29


RalfJ (Aug 29 2019 at 06:45, on Zulip):

I am not sure how much time I'll have today, so I figured I would start asynchronously... is there much to talk about?
I propose we merge https://github.com/rust-lang/unsafe-code-guidelines/pull/186 and https://github.com/rust-lang/unsafe-code-guidelines/pull/161 -- both have green light from @gnzlbg and me, so if @rkruppe or someone else also r+'s we are good to go.
I think we should wait with https://github.com/rust-lang/unsafe-code-guidelines/pull/197, based on the last comment I posted there.

gnzlbg (Aug 29 2019 at 07:37, on Zulip):

+1

gnzlbg (Aug 29 2019 at 07:39, on Zulip):

I'll rebase #153 and will start updating things there

nikomatsakis (Aug 29 2019 at 15:13, on Zulip):

Hey all

nikomatsakis (Aug 29 2019 at 15:13, on Zulip):

I've seen some mentions from here

nikomatsakis (Aug 29 2019 at 15:13, on Zulip):

I'm sorry for being so unresponsive

nikomatsakis (Aug 29 2019 at 15:14, on Zulip):

I've marked this stream as read at some point without really catching up -- was too far behind -- but I'm happy to be repinged on things I'm holding up. I've also been thinking that we're due for another conversation about how to "integrate" UCG and T-lang efforts more tightly. This seems obviously quite relevant in the async I/O effort

RalfJ (Aug 29 2019 at 16:55, on Zulip):

@nikomatsakis check the UCG repository diff if you want to catch up. then you can skip all the long discussions we had and just see the conclusions. ;)

gnzlbg (Aug 29 2019 at 18:09, on Zulip):

@nikomatsakis while not much progress has happened for validity, we have made a bit of progress for layout, defining things like padding, added most basic layout guarantees, and identifying work that remains to be done (properly specifying layout for repr(C) unions, and defining layout for uninhabited types).

gnzlbg (Aug 29 2019 at 18:09, on Zulip):

the validity of fn ptrs is pretty much there, and I'd guess when can already word validity for product types

gnzlbg (Aug 29 2019 at 18:10, on Zulip):

the validity of references seems to have reached a stable point, but @RalfJ might be able to expand on that

RalfJ (Aug 29 2019 at 18:11, on Zulip):

stable maybe, not sure if we're done with all the trade-offs

RalfJ (Aug 29 2019 at 18:11, on Zulip):

I feel validity of ints is more stable. or is there still anyone opposed to allowing uninit ints (and declaring any arithmetical, logical or other operation on them UB)?

gnzlbg (Aug 29 2019 at 18:13, on Zulip):

i think i've made my peace with that

gnzlbg (Aug 29 2019 at 18:14, on Zulip):

(I think i commented there that a PR for adding the validity of int as uninit is ok would be fine for me?)

gnzlbg (Aug 29 2019 at 18:15, on Zulip):

maybe we could at least add a PR with a summary of the rationale ?

RalfJ (Aug 29 2019 at 18:16, on Zulip):

"writeup-needed" or so?

gnzlbg (Aug 29 2019 at 18:16, on Zulip):

it's a binary option, so either way the rationale needs to contains pros/cons of both, and explain why we pick one

gnzlbg (Aug 29 2019 at 18:16, on Zulip):

yeah

RalfJ (Aug 29 2019 at 18:18, on Zulip):

well I'm gone for most of the next 5 weeks, I am not comitting to anything right now I am afraid

gnzlbg (Aug 29 2019 at 18:26, on Zulip):

@RalfJ i'm going to post that the first step is summarzing the pros / cons - that feels worth doing before actually writing the value representation of these types down.

RalfJ (Aug 29 2019 at 18:28, on Zulip):

we also need to find some way to future proof for whatever LLVM ends up doing wrt. provenance

gnzlbg (Aug 29 2019 at 18:30, on Zulip):

you mean if integers carry pointer provenance ?

gnzlbg (Aug 29 2019 at 18:31, on Zulip):

does that affect the validity of integers themselves ?

gnzlbg (Aug 29 2019 at 18:31, on Zulip):

of course, if the integer is part of a pointer that's part of the integer value

gnzlbg (Aug 29 2019 at 18:32, on Zulip):

I think I'm fine with a summary first, and then writing the value representation of integers without provenance

gnzlbg (Aug 29 2019 at 18:32, on Zulip):

we can always launder these integers in LLVM

gnzlbg (Aug 29 2019 at 18:32, on Zulip):

(by doing something like black_box)

RalfJ (Aug 29 2019 at 18:35, on Zulip):

does that affect the validity of integers themselves ?

see what I wrote in the fn ptr RFC PR

RalfJ (Aug 29 2019 at 18:37, on Zulip):

basically it might end up happening that transmuting a pointer to an int gives poison in LLVM. so we could make that UB or "uninitialized integer", but either way it gets reflected in the representation relation.

gnzlbg (Aug 29 2019 at 23:54, on Zulip):

hadnt seen that yet

Last update: Nov 19 2019 at 18:10UTC