Date: Sun, 24 Aug 2025 17:00:11 -0700
> On Aug 24, 2025, at 2:44 PM, organicoman via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
>
>> > Right. You want to pass a library a non-copy that's nullable and you
>> > don't want the library to delete it, and there's teamwork
>> > between you and the library.
>> >
>> > Pass that library a std::optional<T&> instead of a T*.
>> >
>> > Unfortunately std::optional doesn't accept references....it's a compilation error.
>>
>> This whole discussion thread is a colossal waste of time, and made
>> worse with such nonsense.
>
> Dear Ville, don't be upset , we all do mistakes.
You have consumed a vast amount of time from a large number of experts and have consistently demonstrated you are uninterested in actually understand the bug category you are trying to fix.
You have failed to explain how your proposal actually helps mitigate UaFs in real world code.
You have failed to explain how you manage the lifetime of the objects containing the references you are using to pass those pointers.
You have not explained how your proposal permits structs to have private data.
As the thread has gone on you have started changing the goalposts: now it is only trying to fix UaFs in allocations with lexical lifetime, but it still fails at that because anything non-trivial means “lexically bound lifetime” fails for anything with non-local lexical lifetime. While *existing* tools can already handle the same cases without changing code.
And now in the last few emails you have started basically saying that functions should encode ownership and lifetime in their naming: which is what already happens in most real world libraries, for the others the ownership is described in the documentation.
But of course that does not prevent or detect mistakes.
When people are talking about about defending against UaF they are meaning:
* compile time errors if at all possible
* defending against code that is wrong - e.g. you don’t *ever* get to respond with “my proposal does not work if people aren’t using my proposal correctly” given it is a memory safety mitigation. We already have existing lifetime mechanisms that are more powerful, more robust, actually communicate semantics, and harder to use incorrectly.
* doesn’t introduce new memory safety complexity (you keep refusing to explain how you protect the lifetime of your now required reference objects and just dismiss it every time it comes up.
>> That facility is in C++26,
>
>
> It's 2025 now " make me live today, kill me tomorrow " or so they say.
What?
If doing something now is so critical then just adopt std::unique_ptr and std::shared_ptr which both work _today_ and do a much better job of mitigating the paths to UaFs than your proposal does.
I was dismayed to come back this afternoon to discover that this thread was _still_ going.
If you really believe this proposal works, please write an actual proposal similar to what you can find at https://www.open-std.org/jtc1/sc22/wg21/docs/papers/
It will need to say what makes it better than existing options, how it interacts with existing code (including how it helps existing code if you believe it does, how it can be adopted over time, etc), how robust the mitigations are, how effective they are if the developer does something wrong (any proposal wanting to address UaF or similar must _assume_ errors on the part of the developer).
This mail thread is making it very difficult to understand what you expect the mode of action to be, and your replies seem to be changing what it is protecting, how it works, etc. A complete paper can describe the actual mode of action, the actual design, etc.
Continuing this thread where you are attempting to answer questions without a static document to explain the actual details mean we are stuck in this position of your answers seeming to shift over time, and it means anyone trying to determine what your proposal is has to read a gigantic, meandering, and hard to read thread (seriously your mail client makes separating your comments from the people you’re replying to _extremely_ hard - I’m having to go through and compare the email you send from the one your replying to and inserting quotation indents).
If you write a full proposal then other people can simply read the proposal first and then provide feedback or ask questions on specific parts and the discussion can be focused.
—Oliver
>
>
>
>> > Right. You want to pass a library a non-copy that's nullable and you
>> > don't want the library to delete it, and there's teamwork
>> > between you and the library.
>> >
>> > Pass that library a std::optional<T&> instead of a T*.
>> >
>> > Unfortunately std::optional doesn't accept references....it's a compilation error.
>>
>> This whole discussion thread is a colossal waste of time, and made
>> worse with such nonsense.
>
> Dear Ville, don't be upset , we all do mistakes.
You have consumed a vast amount of time from a large number of experts and have consistently demonstrated you are uninterested in actually understand the bug category you are trying to fix.
You have failed to explain how your proposal actually helps mitigate UaFs in real world code.
You have failed to explain how you manage the lifetime of the objects containing the references you are using to pass those pointers.
You have not explained how your proposal permits structs to have private data.
As the thread has gone on you have started changing the goalposts: now it is only trying to fix UaFs in allocations with lexical lifetime, but it still fails at that because anything non-trivial means “lexically bound lifetime” fails for anything with non-local lexical lifetime. While *existing* tools can already handle the same cases without changing code.
And now in the last few emails you have started basically saying that functions should encode ownership and lifetime in their naming: which is what already happens in most real world libraries, for the others the ownership is described in the documentation.
But of course that does not prevent or detect mistakes.
When people are talking about about defending against UaF they are meaning:
* compile time errors if at all possible
* defending against code that is wrong - e.g. you don’t *ever* get to respond with “my proposal does not work if people aren’t using my proposal correctly” given it is a memory safety mitigation. We already have existing lifetime mechanisms that are more powerful, more robust, actually communicate semantics, and harder to use incorrectly.
* doesn’t introduce new memory safety complexity (you keep refusing to explain how you protect the lifetime of your now required reference objects and just dismiss it every time it comes up.
>> That facility is in C++26,
>
>
> It's 2025 now " make me live today, kill me tomorrow " or so they say.
What?
If doing something now is so critical then just adopt std::unique_ptr and std::shared_ptr which both work _today_ and do a much better job of mitigating the paths to UaFs than your proposal does.
I was dismayed to come back this afternoon to discover that this thread was _still_ going.
If you really believe this proposal works, please write an actual proposal similar to what you can find at https://www.open-std.org/jtc1/sc22/wg21/docs/papers/
It will need to say what makes it better than existing options, how it interacts with existing code (including how it helps existing code if you believe it does, how it can be adopted over time, etc), how robust the mitigations are, how effective they are if the developer does something wrong (any proposal wanting to address UaF or similar must _assume_ errors on the part of the developer).
This mail thread is making it very difficult to understand what you expect the mode of action to be, and your replies seem to be changing what it is protecting, how it works, etc. A complete paper can describe the actual mode of action, the actual design, etc.
Continuing this thread where you are attempting to answer questions without a static document to explain the actual details mean we are stuck in this position of your answers seeming to shift over time, and it means anyone trying to determine what your proposal is has to read a gigantic, meandering, and hard to read thread (seriously your mail client makes separating your comments from the people you’re replying to _extremely_ hard - I’m having to go through and compare the email you send from the one your replying to and inserting quotation indents).
If you write a full proposal then other people can simply read the proposal first and then provide feedback or ask questions on specific parts and the discussion can be focused.
—Oliver
Received on 2025-08-25 00:00:28