#rust-lang

ah, yes

the C standard is not perfect

it's... pretty crap, in fact

I'm quite sure practical compiler use "accessed" to mean "read"

they also use it to mean write

otherwise, they couldn't optimize this:

void foo(int* x, short const* y) { *x = *y * 2; *x = *y * 2; *x = *y * 2; }

because you could be doing

short x = 1; foo((int*)&x, &x);

guess I should probably make the second type bigger...

ubsan: that would be UB

because the read at statement 2 would sync with the write at statement 1

arielby: why?

what

after the first write, the stored type is int

and then the second read is UB

because short is not TBAA-compatible with int

okay, sure

your reading works

hmm...

I think you're right, actually

ubsan: and memcpy

yeah, it has to be a primitive

because slices

arielby: with memcpy:

and yeah, if we have memcpy as a primitive, unaligned_read is semi-redundant

except for guaranteeing no copies

but finding the best set of primitives is not something we want to get to

The effective type of an object for an access to its stored value is the declared type of the object, if any. If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value. If a value is copied into an object

having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one. For all other accesses to an object having no declared type, the effective type of the object is simply the type of the lvalue used for the access.

ubsan: memcpy does char writes

and char is TBAA-compatible with anything

yeah

just showing what effective type is

" If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value. "

?

that sounds bad

yeah

TBAA is awful

the "write-to-read" variant is OK

I mean, LLVM-style TBAA

and that's what compilers in practice use

'kay

I'll trust you there

I have to read about it

anyways, so, the point is

besides all the TBAA stuff

memcpy is, I would argue, a primitive

ptr::copy_nonoverlapping

and, secondly, transmute_copy might take DSTs for T

it would make it a heck of a lot more useful

but that's not really what interests me

nmatsakis: casts!

:)

yes!

ubsan: ok

so we'll write transmute_copy in terms of copy_nonoverlapping

yeah

nmatsakis: basically, right now, there are two options for casts which are both hella overloaded

as

and you know my stance on transmute :3

basically, I want to create a rust where there are four cast types: as, transmute, lifetime_cast, and ptr_cast

`as` will be for safe casts, like usize as u32, or fn() as u8

`transmute` will be for bitcasts, like struct X { u32 } -> u32

lifetime_cast will allow for both lifetime shortening *and* lengthening, of any lifetime included

(in the type)

ubsan: we basically got casts from C++

arielby: right, exactly

that's where the inspiration comes from

because we couldn't be bothered to declare an intrinsic for everything

ubsan: I like the sound of this, certainly

ermm

if it was up to me, float <-> int would be an intrinsic

not a cast

arielby: C++ has their shit together :P

they have all the casts

I am imagining that you are envisioning things like lifetime_cast<T>(U)

we got our casts from C :3

i.e., a keyword?

nmatsakis: well, originally

since you're citing C++ :)

but scott wants it to be an intrinsic

and I'm fine with that

(the other big factor in our cast story has been constant expressions; we've often tried to remove `as` but run up against that wall)

ubsan: intrinsic-like-things should be intrinsics

arielby: yeah, makes sense

yeah, an intrinsic seems fine.

so, finally

ptr_cast

which is an unsafe cast

the only reason `as` is not, imo, is the const fn thing I was mentioning

that is, that we didn't have it at the time when we were talking about it, and weren't sure about adding it

I think moving casts -> intrinsics is definitely doubling down on const fn, which is a thing to think about, but I don't see that as esp. controversial these days

nmatsakis: it is also oddly-typed

which turns any pointer into any other, and also turns a usize|isize into a pointer

which means no more transmute for void* -> fn()

that was a weird mix of C and rust

nmatsakis: cool :)

ubsan: pointer, not reference

arielby: pointer, including reference

ptr -> ref casts != ref -> ptr casts

yes

but this does both

'swhy it's unsafe

I remain ... pretty unpersuaded that it is worth distinguishing fn pointers from other pointers. Or, maybe, pretty unsure how to handle portability in cases like these.

but anyway the broad strokes of the idea seem good to me

nmatsakis: the issue is that you can't use `as` with fn()

so you end up using transmute

this has you not use transmute for that

and I think giving intentionality to the purpose of your cast (a la C++) has to be a win

yeah :)

ok maybe I misunderstood what you were saying re: fn

yeah, the point is to make them less specialized

and if an impl *can't* convert, well then, it wouldn't allow those conversions

ubsan: I think that now

the C-enum+char+bool -> int casts

should be discriminant_value

arielby: I feel like that's too specialized

ubsan: we already have discriminant_value

I would want something that goes int->int and C-enum+char+bool->int and u8|i8->char

playbot: -1i8 as char

huh

okay, well, u8->char

ubsan: so u8 -> char is the odd one out

oh, and flt->int and int->flt and flt->flt

of course

call it something like "prim_cast"

ubsan: you create chars via transmute anyway

so I say just nix it

or have an unsafe version so you don't need to transmute or w/e

char::from_u32_unchecked

arielby: hmm?

like, nix the u8->char cast?

yea

you can `char::from_u32_unchecked(c as u32)`

I'd want char::from_u8(c)