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

Topic: Writes to raw pointers considered harmful


RalfJ (Jul 01 2019 at 17:51, on Zulip):

Who else has written things like *raw_ptr = <...> and forgot that this will drop the old content in there and you should really use ptr.write? I certainly have, and this is also very easy to miss in a review.
So, would it be a good idea to lint against such raw pointer writes unless the type does not need dropping, and suggest using a yet-to-be-introduced ptr.write_and_drop method instead?

gnzlbg (Jul 01 2019 at 17:54, on Zulip):

At some point, I stopped dereferencing raw pointers completely, and only use read/write methods, manually dropping when needed. The only time I dereference raw pointers is when I need a reference to the object in the memory location (&*ptr). So yeah, a ptr.write_and_drop method would make some code clearer. It is also kind of easy to forget that write doesn't drop.

RalfJ (Jul 01 2019 at 17:55, on Zulip):

It is also kind of easy to forget that write doesn't drop.

true

Lokathor (Jul 02 2019 at 02:07, on Zulip):

Having a raw pointer to a type that isn't Copy is already a special kind of crazy.

Nicole Mazzuca (Jul 02 2019 at 06:56, on Zulip):

I agree that * on raw pointers is nearly always a bad idea, and I've had so many bugs that could be fixed by not allowing it (while I've never actually needed *, except for turning a raw pointer into a reference)

RalfJ (Jul 02 2019 at 07:26, on Zulip):

no reason to disallow it with Copy types though?

gnzlbg (Jul 02 2019 at 07:30, on Zulip):

what's the advantage of allowing it ? ptr.read() works for Copy too - but now its 2 things you need to learn
and &*ptr and &ptr.read() do 2 subtly different things

gnzlbg (Jul 02 2019 at 07:32, on Zulip):

when working with pointers i wish we had named methods for the basics:

gnzlbg (Jul 02 2019 at 07:35, on Zulip):

The defaults should be unaligned memory operations, so you need then variants for _aligned operations.
You also need variants for _volatile, _atomic, and _volatile_atomic.

gnzlbg (Jul 02 2019 at 07:35, on Zulip):

But while verbose, at least the API would be IMO boring and unsurprising.

Tom Phinney (Jul 02 2019 at 13:51, on Zulip):

Why not create the full set of such variants, omitting those combinations (if any) that are intrinsically incompatible? The full set would be 5 * 2^3 = 40 primitives.

It may be infeasible to suggest deprecating the older non-self-documenting forms, but even so the full list would help make Rustaceans aware of the alternative choices they should consider when using raw pointers. In terms of syntax, I suggest appending the suffixes in the order _volatile, _atomic, _aligned.

Lokathor (Jul 02 2019 at 17:36, on Zulip):

the advantage of allowing it is that pointers work ergonomically :P

RalfJ (Jul 02 2019 at 18:04, on Zulip):

well I think making unaligned the default, that ship has sailed

RalfJ (Jul 02 2019 at 18:05, on Zulip):

and in terms of compatibility, there is no reason to cause all the churn involves in people using raw pointers with Copy types

RalfJ (Jul 02 2019 at 18:05, on Zulip):

I am not talking about "what would we do if this was pre-1.0", that ship has sailed^^

RalfJ (Jul 02 2019 at 18:05, on Zulip):

I am trying to see if we can come up with a proposal that has a remote chance of being accepted today

Lokathor (Jul 03 2019 at 03:57, on Zulip):

So, I think we should more clearly enumerate the main use cases here, then we'll know more of what the problem might look like.

raw pointers that I use are usually for:
, Copy types, so whatever
, FFI opaque data which must be cleaned up with a foreign call (usually during Drop)

Are there other common use cases for pointers that I'm missing where you'd accidentally forget to Drop a value.

RalfJ (Jul 03 2019 at 18:18, on Zulip):

Any type, when you need aliasing

RalfJ (Jul 03 2019 at 18:18, on Zulip):

pointers to uninitialized data

RalfJ (Jul 22 2019 at 13:38, on Zulip):

I suggested a clippy lint: https://github.com/rust-lang/rust-clippy/issues/4294

Last update: Nov 19 2019 at 17:40UTC