There is no lang item that makes + an unsafe operation

[mahkoh]

impl<T: ?Sized> Add<usize> for *mut T

relies on the user knowing about the unsafety.

[huonw]

Hm, I'm confused; where is this impl? grep doesn't find anything in core, and fn main() { (0 as *mut u8) + 1; } doesn't compile. Could you clarify?

[mahkoh]

It doesn't exist in the standard library that comes with the distribution.

[arielb1]

@mahkoh

Of course it does not. Carelessly using pointer arithmetic can invoke UB very easily. That's why we put it behind <*T>::offset.

[mahkoh]

ptr.offset(1);
ptr + 1;

Wow, offset is obviously much safer and makes the code easier to read. Clearly this has nothing to do with the lack of unsafe operators. My bad.

[pnkfelix]

@mahkoh this style of conversation is unproductive, and you know it violates community norms. Your constant search for ways to express yourself that antagonize the community wastes a lot of everyone's time.

if this bug is "we need a variant of the Add trait where the add method is marked unsafe, so that uses of a + b for such implementing types can be forced to be in unsafe blocks", then that is indeed something to discuss, but probably should be coupled with rust-lang/rfcs#420, since as @huonw stated already, we do not have an impl<T: ?Size> Add<usize> for *mut T.

If this bug is "i would like ptr + 1 to work for ptr : *mut T or ptr: *const T, out of the box with the std lib, but have it forced to be in unsafe blocks since it may break requirements of e.g. LLVM", then that is a separate (though obviously related) issue to the one outlined in the prior paragraph.

But it is not clear what is actionable today to address this issue. Especially since it is quite unclear what the actual issue is.

[mahkoh]

it is quite unclear what the actual issue is.

You seem to have missed the title of the issue:

There is no lang item that makes + an unsafe operation

What exactly is unclear about that?

i would like ptr + 1 to work for ptr : *mut T or ptr: *const T, out of the box with the std lib,

Mozilla's standard library is completely irrelevant when it comes to lang items that are a feature of the language. ptr + 1 already works in other people's standard libraries but has to come with a big warning in the documentation that it's unsafe.

[Diggsey]

Surely by rust's logic, pointer arithmetic is not unsafe, for the same reason that converting a reference to a pointer is not unsafe: it's only unsafe to actually dereference such a pointer?

Regardless, it seems quite plausible that there might be other cases where addition/other operator should be unsafe, but the "more flexible operator overloading" rfc would fix that.

[arielb1]

@Diggsey

Invalid pointer arithmetic is LLVM UB - if you do it, LLVM will "miscompile" your code.

@mahkoh

Rust is meant to be used with libcore. Because of the orphan rules, the only crate which can implement + for unsafe ptrs is libcore. It doesn't and won't, intentionally.

Anyway, adding a lang-item that makes + unsafe is RFC territory, and is currently a part of rust-lang/rfcs#420.

[kmcallister]

this style of conversation is unproductive, and you know it violates community norms

The core team won't enforce the code of conduct on our GitHub threads. Rather the "norm" that's been established is infinite excuses and "last" chances for this kind behavior. mahkoh has been at it for at least 5 months (I can provide specific links) and strcat was tolerated for several years.

Don't be surprised when you start to lose more contributors over breaking the promise the CoC represents. I won't be the last one.

[mahkoh]

Surely by rust's logic, pointer arithmetic is not unsafe, for the same reason that converting a reference to a pointer is not unsafe:

It's unsafe because rustc uses the LLVM inbounds attribute and LLVM says that invalid pointer arithmetic with this attribute is UB even if the pointer is never used afterwards.

Edit: I guess this only applies if you use the offset intrinsic but the offset intrinsic supposedly enables more optimizations compared to as usize + 1) as *mut T.

Rust is meant to be used with libcore

I'm using it without libcore.

[arielb1]

@kmcallister

Well, str​cat's objections at least were smart.

@mahkoh

Providing your own libcore isn't supported.

[arielb1]

Could someone close this?

[mahkoh]

@arielb1 It was my pleasure.

[mahkoh]

If this repo cannot even be used for language only topics that are unrelated to the garbage that is the rest of the distribution then it's pretty useless. That is very good to know!