Date: Tue, 14 Oct 2025 19:12:35 -0400
On 10/14/25 5:47 PM, Ville Voutilainen wrote:
> On Wed, 15 Oct 2025 at 00:41, Tom Honermann <tom_at_[hidden]> wrote:
>>>> Violating preconditions of, e.g., span<...>::operator[], resulting in UB is not new. Implementations are not required to offer a hardened implementation.
>>> Yes? And? Violating *hardened* preconditions resulting in UB *is* new.
>> Prior to hardened preconditions being added to the standard, violating
>> any precondition resulted in UB. Now, some of those previous
>> preconditions are deemed hardened and violating them is a contract
>> violation that, if evaluated with a non-terminating contract semantic,
>> results in ... UB. If you mean that the standard now includes an
>> additional use of the words "undefined behaavior" that will presumably
>> demand a reference from the UB annex, then sure, I guess that is new in
>> some sense. But for programmers, the UB isn't what is new; the contract
>> checks are what is new.
> Please read what I actually wrote.
I have been, but I'm afraid we still seem to be failing to communicate
effectively despite my best efforts.
>
> For programmers, modulo when using libc++, and on a longer timescale,
> even then, violating hardened preconditions resulting
> in UB is new.
>
> What is new to the standard is beside the point there.
>
> Your statement that prior to hardened preconditions being added to the
> standard, violation of any precondition resulted in UB
> is correct from the perspective of the standard text in isolation, and
> incorrect for practical programmers when using a hardened
> implementation. They didn't hit UB,
> they had a guarantee that they will not hit abstract machine UB.
Yes, so they relied on an implementation provided guarantee that wasn't
backed by the standard. And implementations can still provide that
guarantee, so users will still be able to rely on an implementation
provided guarantee. That is why I'm saying I don't see anything new or
problematic here. The status quo doesn't actually change as far as I can
tell.
It sounds like you want the standard to now provide a guarantee; one
that libc++ doesn't currently provide. That's fine of course, but I
don't see how that introduces new UB to existing implementations.
My expectation is that standard library implementations will not tie
their choice of a contract semantic for hardened precondition to any
particular choice of contract semantic for user written contract
assertions and will instead rely on some other implementation dependent
way to select a contract semantic for hardened preconditions. Do you
have a different expectation?
Tom.
>
> Before someone chooses to explain to me that they did hit UB but the
> implementation defined it, spare me, you're not telling me anything I
> don't already know.
> On Wed, 15 Oct 2025 at 00:41, Tom Honermann <tom_at_[hidden]> wrote:
>>>> Violating preconditions of, e.g., span<...>::operator[], resulting in UB is not new. Implementations are not required to offer a hardened implementation.
>>> Yes? And? Violating *hardened* preconditions resulting in UB *is* new.
>> Prior to hardened preconditions being added to the standard, violating
>> any precondition resulted in UB. Now, some of those previous
>> preconditions are deemed hardened and violating them is a contract
>> violation that, if evaluated with a non-terminating contract semantic,
>> results in ... UB. If you mean that the standard now includes an
>> additional use of the words "undefined behaavior" that will presumably
>> demand a reference from the UB annex, then sure, I guess that is new in
>> some sense. But for programmers, the UB isn't what is new; the contract
>> checks are what is new.
> Please read what I actually wrote.
I have been, but I'm afraid we still seem to be failing to communicate
effectively despite my best efforts.
>
> For programmers, modulo when using libc++, and on a longer timescale,
> even then, violating hardened preconditions resulting
> in UB is new.
>
> What is new to the standard is beside the point there.
>
> Your statement that prior to hardened preconditions being added to the
> standard, violation of any precondition resulted in UB
> is correct from the perspective of the standard text in isolation, and
> incorrect for practical programmers when using a hardened
> implementation. They didn't hit UB,
> they had a guarantee that they will not hit abstract machine UB.
Yes, so they relied on an implementation provided guarantee that wasn't
backed by the standard. And implementations can still provide that
guarantee, so users will still be able to rely on an implementation
provided guarantee. That is why I'm saying I don't see anything new or
problematic here. The status quo doesn't actually change as far as I can
tell.
It sounds like you want the standard to now provide a guarantee; one
that libc++ doesn't currently provide. That's fine of course, but I
don't see how that introduces new UB to existing implementations.
My expectation is that standard library implementations will not tie
their choice of a contract semantic for hardened precondition to any
particular choice of contract semantic for user written contract
assertions and will instead rely on some other implementation dependent
way to select a contract semantic for hardened preconditions. Do you
have a different expectation?
Tom.
>
> Before someone chooses to explain to me that they did hit UB but the
> implementation defined it, spare me, you're not telling me anything I
> don't already know.
Received on 2025-10-14 23:12:41
