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

Topic: meeting-2019-04-11


RalfJ (Apr 11 2019 at 15:14, on Zulip):

Hi @WG-unsafe-code-guidelines !

Alan Jeffrey (Apr 11 2019 at 15:15, on Zulip):

:wave:

RalfJ (Apr 11 2019 at 15:17, on Zulip):

@nikomatsakis @gnzlbg @avadacatavra

RalfJ (Apr 11 2019 at 15:17, on Zulip):

is there anything to discuss? we have two open PRs by @gnzlbg

RalfJ (Apr 11 2019 at 15:18, on Zulip):

and also the GH pages book publishing thing still doesnt work, AFAIK

RalfJ (Apr 11 2019 at 15:18, on Zulip):

not sure who can do what about that though

RalfJ (Apr 11 2019 at 15:19, on Zulip):

Also sorry for just missing last week's meeting, I was travelling and forget to tell y'all. I guess today I get to see how that feels from the other side ;)

gnzlbg (Apr 11 2019 at 15:21, on Zulip):

:hi:

nikomatsakis (Apr 11 2019 at 15:21, on Zulip):

:wave:

nikomatsakis (Apr 11 2019 at 15:21, on Zulip):

I'm back from traveling and things too this week

nikomatsakis (Apr 11 2019 at 15:22, on Zulip):

and also the GH pages book publishing thing still doesnt work, AFAIK

ok sorry this is probably my fault

gnzlbg (Apr 11 2019 at 15:22, on Zulip):

i couldn't manage to properly update the deploy key to travis

nikomatsakis (Apr 11 2019 at 15:22, on Zulip):

OK, let me see if I can fix it.

RalfJ (Apr 11 2019 at 15:22, on Zulip):

:)

RalfJ (Apr 11 2019 at 15:22, on Zulip):

@gnzlbg what is the status of your PRs?

gnzlbg (Apr 11 2019 at 15:22, on Zulip):

alex mentioned that we shouldn't use github tokens, but deploy keys instead

gnzlbg (Apr 11 2019 at 15:23, on Zulip):

i don't remember what those were about

nikomatsakis (Apr 11 2019 at 15:23, on Zulip):

Oh? (cc @Alex Crichton) I don't know anything about deploying keys

RalfJ (Apr 11 2019 at 15:23, on Zulip):

If T is sized, references and pointers to T have a size and alignment of one
word and have therefore the same layout as C pointers.

RalfJ (Apr 11 2019 at 15:23, on Zulip):

https://github.com/rust-lang/unsafe-code-guidelines/pull/100

RalfJ (Apr 11 2019 at 15:23, on Zulip):

seems fine to merge?

RalfJ (Apr 11 2019 at 15:24, on Zulip):

nobody complained for 4 weeks^^

gnzlbg (Apr 11 2019 at 15:24, on Zulip):

That one seems to just fix an omission in the layout of ptrs sections, right ?

RalfJ (Apr 11 2019 at 15:24, on Zulip):

I guess so

nikomatsakis (Apr 11 2019 at 15:24, on Zulip):

that seems fine to me except i'm not sure about the word "word"

nikomatsakis (Apr 11 2019 at 15:24, on Zulip):

like, is that defined and well understood?

nikomatsakis (Apr 11 2019 at 15:24, on Zulip):

I guess "same as C pointers" is pretty clear :)

RalfJ (Apr 11 2019 at 15:25, on Zulip):

that term is also used a lot in the same document

nikomatsakis (Apr 11 2019 at 15:25, on Zulip):

ok

nikomatsakis (Apr 11 2019 at 15:25, on Zulip):

then fine

RalfJ (Apr 11 2019 at 15:25, on Zulip):

but I agree with the concern

gnzlbg (Apr 11 2019 at 15:25, on Zulip):

good question, word size == pointer size, but maybe we should just define word somewhere as "something pointer sized"

gnzlbg (Apr 11 2019 at 15:25, on Zulip):

in that case it seems redundant there

RalfJ (Apr 11 2019 at 15:25, on Zulip):

seems worth adding to the "terminology" section that this document has

RalfJ (Apr 11 2019 at 15:26, on Zulip):

is that universally correct? like, I am thinking of CHERI here

gnzlbg (Apr 11 2019 at 15:26, on Zulip):

or we should just not use "word" and just say "pointer-sized", size of a pointer, etc.

gnzlbg (Apr 11 2019 at 15:26, on Zulip):

i mean, in CHERI pointers are 128-bit wide, that would be true for both Rust and C

RalfJ (Apr 11 2019 at 15:26, on Zulip):

yes but does that really make CHERI's word size 128 bits

gnzlbg (Apr 11 2019 at 15:27, on Zulip):

so.. a word in CHERI would be 128-bit i suppose, this is confusiong, I really would prefer to just talk about pointer sizes

RalfJ (Apr 11 2019 at 15:27, on Zulip):

I'd imagine for, e.g. CHERI-MIPS if this is 64bit MIPS with CHERI extensions, the word size would still be considered 64bits

Alex Crichton (Apr 11 2019 at 15:27, on Zulip):

@nikomatsakis @gnzlbg I'd prioritize getting something working, but if you're setting up CI I'd recommend using a deploy key instead of a token so it's scoped to just one repo rather than "all repos the user who created the token has access to"

RalfJ (Apr 11 2019 at 15:27, on Zulip):

but maybe that's too weird to be a concern right now

gnzlbg (Apr 11 2019 at 15:27, on Zulip):

@Alex Crichton that's what I did, but I don't appear to have enough permission to upload the deploy key to travis or something like that

RalfJ (Apr 11 2019 at 15:28, on Zulip):

and for Rust, "word" = "size of usize"

RalfJ (Apr 11 2019 at 15:28, on Zulip):

anyway that's a separate PR/issue, let's merge this one

gnzlbg (Apr 11 2019 at 15:28, on Zulip):

maybe we should just open an issue about the word "word" and either add it to the glossary, or remove it. IIRC that was the only document that uses it

RalfJ (Apr 11 2019 at 15:29, on Zulip):

:+1: do you want to do that?

RalfJ (Apr 11 2019 at 15:30, on Zulip):

the other PR is https://github.com/rust-lang/unsafe-code-guidelines/pull/98. That diff is hard to read because it also moves stuff around.

RalfJ (Apr 11 2019 at 15:31, on Zulip):

and then it also does the "maximal object size" thing

gnzlbg (Apr 11 2019 at 15:31, on Zulip):

https://github.com/rust-lang/unsafe-code-guidelines/issues/109

gnzlbg (Apr 11 2019 at 15:31, on Zulip):

we don't guarantee anything about "maximal object size" there I think, just document how its currently implemented

nikomatsakis (Apr 11 2019 at 15:32, on Zulip):

so the uint8_t == u8 etc seems :+1: to me

nikomatsakis (Apr 11 2019 at 15:32, on Zulip):

I'm skimming the rest

gnzlbg (Apr 11 2019 at 15:32, on Zulip):

there is an issue open about whether we should guarantee anything at all about the maximum size of Rust objects or not: https://github.com/rust-lang/unsafe-code-guidelines/issues/102

RalfJ (Apr 11 2019 at 15:32, on Zulip):

well it says something about "the maximum size of Rust _values_ is limited to isize::max_value()"

gnzlbg (Apr 11 2019 at 15:33, on Zulip):

sure, but it says so in a n"ote: in the current implementation..."... right?

RalfJ (Apr 11 2019 at 15:33, on Zulip):

yes

RalfJ (Apr 11 2019 at 15:33, on Zulip):

but then there was this discussion about "value" or "object" or "allocation" or whatever

gnzlbg (Apr 11 2019 at 15:33, on Zulip):

There was a thread there were we decided to not guarantee anything

gnzlbg (Apr 11 2019 at 15:33, on Zulip):

That's https://github.com/rust-lang/unsafe-code-guidelines/pull/40

RalfJ (Apr 11 2019 at 15:34, on Zulip):

no its https://github.com/rust-lang/unsafe-code-guidelines/pull/98#discussion_r266196387

gnzlbg (Apr 11 2019 at 15:34, on Zulip):

once that is merged, somebody needs to do a pass through the whole document, and make it consistent

RalfJ (Apr 11 2019 at 15:34, on Zulip):

I concur with what @rkruppe says there

RalfJ (Apr 11 2019 at 15:35, on Zulip):

"allocations" (on the heap, the stack or elsewhere) are the better term

RalfJ (Apr 11 2019 at 15:35, on Zulip):

in particular, the limit applies even to just calling the alloc function without putting any "value" into it

gnzlbg (Apr 11 2019 at 15:35, on Zulip):

shouldn't that be places ?

RalfJ (Apr 11 2019 at 15:35, on Zulip):

places are an ephemeral concept arising during evaluation of some statements

gnzlbg (Apr 11 2019 at 15:35, on Zulip):

also this affects the size of temporaries without a real place

gnzlbg (Apr 11 2019 at 15:36, on Zulip):

(I think, e.g., if an expression produces a value that's too large)

nikomatsakis (Apr 11 2019 at 15:36, on Zulip):

"allocations" (on the heap, the stack or elsewhere) are the better term

this sounds correct to me too; but modulo the terminology, the overall approach of the PR seems right (documenting limits + current behavior)

RalfJ (Apr 11 2019 at 15:37, on Zulip):

on the LLVM level there is no such thing as a "value" not backed by an allocation

gnzlbg (Apr 11 2019 at 15:37, on Zulip):

and on MIR ?

RalfJ (Apr 11 2019 at 15:37, on Zulip):

let me go look that up in the MIR spec... ;)

RalfJ (Apr 11 2019 at 15:37, on Zulip):

in Miri, there is not

RalfJ (Apr 11 2019 at 15:37, on Zulip):

but there are different ways to write the spec

gnzlbg (Apr 11 2019 at 15:37, on Zulip):

this is a limit on the size of the result of any expression as well

RalfJ (Apr 11 2019 at 15:38, on Zulip):

(well, there is not except for "immediates", which are basically scalars, plus fat pointers)

RalfJ (Apr 11 2019 at 15:38, on Zulip):

yes but that result is put into an allocation

RalfJ (Apr 11 2019 at 15:38, on Zulip):

so the term covers that case

gnzlbg (Apr 11 2019 at 15:38, on Zulip):

so what's the difference between an allocation and a place ?

RalfJ (Apr 11 2019 at 15:38, on Zulip):

we should probably come back to this once ucg#40 is resolved

RalfJ (Apr 11 2019 at 15:38, on Zulip):

an allocation is an entity in the machine state

RalfJ (Apr 11 2019 at 15:38, on Zulip):

it has properties such as alignment, size, blah

RalfJ (Apr 11 2019 at 15:39, on Zulip):

a place arises ephemerally during evaluation of a statement, and is basically a synonym for "location" (!= allocation)

RalfJ (Apr 11 2019 at 15:39, on Zulip):

in particular a place can point to part of an allocation, like &(1,2).1

gnzlbg (Apr 11 2019 at 15:40, on Zulip):

i think we should document that in the glossary, I'll change the PR to say allocation there, and then I'll merge

RalfJ (Apr 11 2019 at 15:40, on Zulip):

well we can document this once we resolved ucg#40 I guess^^

RalfJ (Apr 11 2019 at 15:40, on Zulip):

and for the bigger picture, once we get a MIR spec

gnzlbg (Apr 11 2019 at 15:41, on Zulip):

i think we can add the definition of "allocation" in parallel right ?

RalfJ (Apr 11 2019 at 15:41, on Zulip):

but judging from how long it takes us to agree on 1 term, the expected time to agree on the framework of terminology in a MIR spec is >10 years :P

RalfJ (Apr 11 2019 at 15:42, on Zulip):

I find it hard to "define" allocation. for me "define" is something mathematical, and to do taht you cannot just define one thing... allocation talks about memory, so you got to define that, and at that point you basically have to define the entire machine model.

RalfJ (Apr 11 2019 at 15:43, on Zulip):

we can "define" in the sense of "putting down some hand-wavy English sentences" but I see little value in that for terms like "allocation", TBH...

RalfJ (Apr 11 2019 at 15:43, on Zulip):

but that is a separate discussion ;)

nikomatsakis (Apr 11 2019 at 15:43, on Zulip):

I think using the term allocation seems good for now. I agree it's meaning seems fairly clear, but I also think defining in the sense of giving a few examples of allocations seems harmless

nikomatsakis (Apr 11 2019 at 15:44, on Zulip):

in particular it's probably worth pointing out that this is not restrictied to "things returned by malloc"

nikomatsakis (Apr 11 2019 at 15:44, on Zulip):

but includes e.g. stack slots

gnzlbg (Apr 11 2019 at 15:44, on Zulip):

i've updated the PR

nikomatsakis (Apr 11 2019 at 15:44, on Zulip):

something else: when we had the lang team sync discussion, one thing I took away was the need for us to not only document conclusions but also the considerations that led to those conclusions

nikomatsakis (Apr 11 2019 at 15:44, on Zulip):

I don't thnk we've done much in that direction so far, right?

gnzlbg (Apr 11 2019 at 15:45, on Zulip):

its in the issues and PRs, but its not part of a document

nikomatsakis (Apr 11 2019 at 15:45, on Zulip):

right, the key point was to extract out from the issues and into the document

nikomatsakis (Apr 11 2019 at 15:45, on Zulip):

or into a document

gnzlbg (Apr 11 2019 at 15:45, on Zulip):

maybe it would be nice to have like drop-down rationale lists that can be expanded to read the rationale of things

gnzlbg (Apr 11 2019 at 15:45, on Zulip):

i mean, inline within the documents

RalfJ (Apr 11 2019 at 15:45, on Zulip):

we could use <details> for that?

nikomatsakis (Apr 11 2019 at 15:45, on Zulip):

I think we were talking about having separate sections

nikomatsakis (Apr 11 2019 at 15:46, on Zulip):

but I'm game for details if that works =)

gnzlbg (Apr 11 2019 at 15:46, on Zulip):

i think i would prefer to have the rationale of each section (or each paragraph) "inline" so that one can quickly read it for the parts that might be unclear, and also make it easy to update.

gnzlbg (Apr 11 2019 at 15:47, on Zulip):

for C++ the rationale was in a different document, and now its 20 years out of date

RalfJ (Apr 11 2019 at 15:48, on Zulip):

got to go to catch a bus, thanks all!

gnzlbg (Apr 11 2019 at 15:49, on Zulip):

@nikomatsakis collecting the whole rationale is going to be a lot of work, for things that stem from RFCs, there was a lot of discussion in the PRs, which is not necessarily accounted for in the RFC rationale and alternatives

nikomatsakis (Apr 11 2019 at 15:50, on Zulip):

yep

nikomatsakis (Apr 11 2019 at 15:50, on Zulip):

luckily almost none of this comes from RFCs :P

nikomatsakis (Apr 11 2019 at 15:50, on Zulip):

(fwiw I think this is a place where our RFC process needs to be updated too)

nikomatsakis (Apr 11 2019 at 15:50, on Zulip):

to do a better job of this

nikomatsakis (Apr 11 2019 at 15:50, on Zulip):

anyway as a first step maybe we can just try to make a list of places we might want to add rationale

gnzlbg (Apr 11 2019 at 15:57, on Zulip):

in many places the rationale is "there wasn't any other reasonable option"

gnzlbg (Apr 11 2019 at 15:58, on Zulip):

should we document those as well ?

nikomatsakis (Apr 11 2019 at 15:59, on Zulip):

seems like it would be valuable to docuent

rkruppe (Apr 11 2019 at 16:00, on Zulip):

In some cases there are "unreasonable" alternatives that were brought up and dismissed, we should document the reasons why they're considered unreasonable.

gnzlbg (Apr 11 2019 at 16:31, on Zulip):

https://github.com/rust-lang/unsafe-code-guidelines/pull/110 shows an example of how that could look like

gnzlbg (Apr 11 2019 at 16:32, on Zulip):

maybe we could make the rationale labels a bit smaller

gnzlbg (Apr 11 2019 at 16:33, on Zulip):

Collapsed:

collapsed.png

Expanded:

expanded.png

Last update: Dec 12 2019 at 01:50UTC