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 toT
have a size and alignment of one
word and have therefore the same layout as C pointers.
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
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
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