Hi @WG-unsafe-code-guidelines !

:wave:

@nikomatsakis @gnzlbg @avadacatavra

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

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

not sure who can do what about that though

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 ;)

:hi:

:wave:

I'm back from traveling and things too this week

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

ok sorry this is probably my fault

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

OK, let me see if I can fix it.

:)

@gnzlbg what is the status of your PRs?

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

i don't remember what those were about

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

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.

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

seems fine to merge?

nobody complained for 4 weeks^^

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

I guess so

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

like, is that defined and well understood?

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

that term is also used a lot in the same document

ok

then fine

but I agree with the concern

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

in that case it seems redundant there

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

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

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

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

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

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

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

@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"

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

@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

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

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

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

:+1: do you want to do that?

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.

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

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

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

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

I'm skimming the rest

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

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

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

yes

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

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

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

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

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

I concur with what @rkruppe says there

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

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

shouldn't that be places ?

places are an ephemeral concept arising during evaluation of some statements

also this affects the size of temporaries without a real place

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

"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)

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

and on MIR ?

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

in Miri, there is not

but there are different ways to write the spec

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

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

yes but that result is put into an allocation

so the term covers that case

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

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

an allocation is an entity in the machine state

it has properties such as alignment, size, blah

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

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

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

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

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

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

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

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.

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...

but that is a separate discussion ;)

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

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

but includes e.g. stack slots

i've updated the PR

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

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

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

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

or into a document

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

i mean, inline within the documents

we could use <details> for that?

I think we were talking about having separate sections

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

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.

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

got to go to catch a bus, thanks all!

@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

yep

luckily almost none of this comes from RFCs :P

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

to do a better job of this

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

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

should we document those as well ?

seems like it would be valuable to docuent

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

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

maybe we could make the rationale labels a bit smaller

Collapsed:

collapsed.png

Expanded:

expanded.png