Date: Wed, 21 Aug 2019 15:30:44 +0200
Hi,
> On 21 Aug 2019, at 15:01, sdkrystian via Std-Proposals <std-proposals_at_[hidden]> wrote:
> Well the implementation of a standard library function by the implementation never invokes UB: they get to break all sorts of rule. It need not even be written in C++.
Sure, but then it would also mean that those functions are essentially unimplementable if you are NOT a compiler vendor. Which is kind of insane imho.
> As for the reason why the first code snippet is UB, it's because as of C++17, pointers point to objects, not addresses. So when we do that reinterpret_cast, there is no existing rule stating that it binds to any char object - it still points to the original object, but through a pointer to a different type. That means, when you perform pointer arithmetic, it violates [expr.add] p6 (type of the pointer is not similar to the type it points to).
Yep, that makes sense and is consistent with the current wording afaics. Thanks for the explanation!
Cheers,
Timur
> On 21 Aug 2019, at 15:01, sdkrystian via Std-Proposals <std-proposals_at_[hidden]> wrote:
> Well the implementation of a standard library function by the implementation never invokes UB: they get to break all sorts of rule. It need not even be written in C++.
Sure, but then it would also mean that those functions are essentially unimplementable if you are NOT a compiler vendor. Which is kind of insane imho.
> As for the reason why the first code snippet is UB, it's because as of C++17, pointers point to objects, not addresses. So when we do that reinterpret_cast, there is no existing rule stating that it binds to any char object - it still points to the original object, but through a pointer to a different type. That means, when you perform pointer arithmetic, it violates [expr.add] p6 (type of the pointer is not similar to the type it points to).
Yep, that makes sense and is consistent with the current wording afaics. Thanks for the explanation!
Cheers,
Timur
Received on 2019-08-21 08:32:50