Conversation

Replying to

and

Rust explicitly defines isize::MAX as the maximum size object that's permitted. Unsafe code needs to uphold this by making sure not to do it. Some malloc implementations like musl & jemalloc have this check internally but Rust has to check itself with an unknown/generic malloc.

1

1

3

Replying to

and

See gcc.gnu.org/bugzilla/show_ for a thread about this. ptrdiff_t+1 or larger objects are just not permitted with LLVM and GCC. It's not a C standard violation but rather they require that all standard ways of allocating objects (C, POSIX) have checks preventing larger objects.

1

Replying to

and

I helped fix multiple malloc and libc implementations but there are still common ones like glibc that are broken with GCC/LLVM. It's a bad idea to use objects larger than PTRDIFF_MAX even with a compiler supporting it since x-y will be undefined if it overflows.

2

William D. Jones

Replying to

and

Just to be crystal clear... by "compiler supporting PTRDIFF_MAX + 1", you mean "the compiler assumes an object of PTRDIFF_MAX + 1 can possibly exist" (and gcc/llvm doesn't)?

1

Replying to

and

Yes, that's what I mean. GCC and LLVM don't support objects larger than PTRDIFF_MAX. It's not seen as a bug but it could be seen as a missing feature. It doesn't appear there's any interest in implementing it though. So, you need a compiler supporting that *and* it's still hard.

1

William D. Jones

Replying to

and

(Honestly, playing with 8088 so much, that gives me some comfort that even on flat addrspace archs, the whole addrspace can't be used for a single object in high-level langs :P)

1

William D. Jones

Replying to

twitter.com/DanielMicay/st I guess my follow up is: what do you mean by it's unrealistic to avoid "x - y" when it overflows? The sentence immediately after describes how gcc/llvm do it... it prevents your program from continuing :)!

Quote Tweet

Replying to @DanielMicay @brouhaha and @iximeow

Even with the C standard semantics, it's unrealistic to avoid x-y when it would overflow. GCC and LLVM don't give you the opportunity to try to use it correctly. It just isn't supported. It's one of many rules they don't really bother to document. It's how they intend it to work.

1

Replying to

and

x - y overflow for pointers is undefined behavior but it's incredibly common to do it with arbitrary slices, etc. in both C and Rust. You can do things in a tricky way with uintptr_t casts but it has an impact on optimization / code generation.

2

1

2

William D. Jones

Replying to

and

So you're basically saying "even though signed overflow is undefined, it's so pervasive in ptr contexts that gcc/llvm won't optimize it out/do cute tricks"?

1

Replying to

and

No, what I'm saying is that even if objects larger than PTRDIFF_MAX were supported by LLVM and GCC, pointer difference overflows would still be undefined. Since it's so common to take differences on arbitrary slices, etc. it would still be undefined to allow making those objects.

1

Replying to

LLVM and GCC do actively break code with signed integer overflows if you aren't passing -fwrapv or -fno-strict-overflow. They're particularly aggressive with breaking it for pointers. They barely have any integer range analysis, etc. so they don't break much with integers.

9:41 PM · Jul 6, 2021Twitter Web App

Replying to

It's not really that they avoid breaking code due to being cautious but rather they're terrible at doing analysis of integer ranges or optimizing based on it. It's a big part of why they both suck at removing bounds checks.

1

1

Replying to

Most languages don't say signed integer overflow is undefined like C and LLVM/GCC won't hold back generic optimizations just to avoid breaking C code. They'll eventually add proper integer range analysis. C programmers can either use -fwrapv or have their undefined code break.

1

1

Show replies