> On Jun 3, 2025, at 2:29 AM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Tue, Jun 3, 2025 at 2:00 AM Oliver Hunt wrote:
>>
>> Here’s what happens when you aren’t compiling for x86_64:
>>
>> Address of stringstream: 0x16efeaf18
>>
>> Address of ostream: 0x16efeaf28
>>
>> [1] 74787 bus error ./a.out
>
>
> I presume that machine you're working on is 64-Bit ARM using the
> aarch64 instruction set?


ARMv8.3, e.g pointer authentication
>
> Here's what you need:
>
> https://godbolt.org/z/aaMjfvbro
>

No. That does not work.

I do not know why you are arguing with me. What you are trying to do does _not_ work.

I gave you multiple godbolt links showing you the required, type specific, codegen required to load the vtable pointer.

After correcting your code to include the required underscores, here is the outcome:

./a.out
Address of stringstream: 0x16bd3eef8
Address of ostream: 0x16bd3ef08
[1] 66169 segmentation fault ./a.out

The fact that you want reality to be one way, does not make that reality.

> I can do this for every compiler, every operating system, every
> instruction set, every CPU. Including when pointer authentication
> comes out for Linux.

No. You cannot. The people bringing up pointer authentication on linux have adopted the darwin ABI for vtable authnetication. So what you are trying to do will not work there either.

> The only one that takes a little more work is
> Microsoft, hence my idea of 'std::polyhandle'.
>
> That GodBolt I gave you just now has no undefined behaviour on 64-Bit ARM.

Correct, it has no UB according to the ISA. Unfortunately this is the C++ standard, and C++ says this is UB. On ARMv8.3, with the darwin c++ abi this triggers process termination.

I have repeatedly explained why what you want to happen does not work on “all platforms”.

I’ve given multiple reasons for why what you want is not reasonable.

I’ve repeatedly explained why the code you have presented is incorrect.

All the while you have repeatedly ignored all of this, demonstrated a complete failure to understand the technical details of anything you have been talking about, and shown a quite frankly bad faith approach to all of this.

Any discussion on this list requires participants engage in a good faith discussion that acknowledges reality, and you are simply refusing to do so.

This list is filled with domain experts who have invested time in responding to you, and have tried to explain to you why your repeated assertions of what is not UB, and at no point have you shown the remotest interest in any of those responses.

Much earlier I said that what you should do is produce a proposal for features that provide what you actually want as an end result, and rather than adjusting your proposal to describe the end goal, you’ve continued to say that the problem is reality, and not your proposal.

Given your attitude, this thread is a waste of my time, and honestly I think the time of the other people on this thread.

—Oliver

> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals