Date: Tue, 21 Oct 2025 09:36:04 +0200
Hi Ville,
> On 21 Oct 2025, at 09:27, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
> Well, here's an easy improvement:
>
> <del>This approach enables the use of ODR checkers and makes unsound
> optimisations that would otherwise break
> the program non-conforming.</del>
>
> Perhaps a more elaborate one would be along the lines of
>
> This approach <del>enables the use of</del><ins>is intended to
> help</ins> ODR checkers <ins>find other ODR violations, unrelated to
> contract</ins> <del>
Thanks, that's indeed an improvement!
> and makes unsound optimisations that would
> otherwise break the program non-conforming</del>.
>
> After all, we seem to have converged on an agreement that
> inter-procedural optimizations based on a locally visible definition
> of an inline function
> are unsound to begin with,
I'm glad we agree :) it follows then that the "supply chain attack" scenario/example described in P3829 is not actually something that the P2900 spec allows. Can we agree on that too?
> so their conformance is.. ..perhaps not so relevant.
I am not sure I follow. If we agree that they are unsound, why would we still want them to be conforming? If we say that they are *not* conforming, we also say that things like the "supply chain attack" scenario/example described in P3829 is something that should never happen. Wouldn't that be a good thing?
Cheers,
Timur
> On 21 Oct 2025, at 09:27, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
> Well, here's an easy improvement:
>
> <del>This approach enables the use of ODR checkers and makes unsound
> optimisations that would otherwise break
> the program non-conforming.</del>
>
> Perhaps a more elaborate one would be along the lines of
>
> This approach <del>enables the use of</del><ins>is intended to
> help</ins> ODR checkers <ins>find other ODR violations, unrelated to
> contract</ins> <del>
Thanks, that's indeed an improvement!
> and makes unsound optimisations that would
> otherwise break the program non-conforming</del>.
>
> After all, we seem to have converged on an agreement that
> inter-procedural optimizations based on a locally visible definition
> of an inline function
> are unsound to begin with,
I'm glad we agree :) it follows then that the "supply chain attack" scenario/example described in P3829 is not actually something that the P2900 spec allows. Can we agree on that too?
> so their conformance is.. ..perhaps not so relevant.
I am not sure I follow. If we agree that they are unsound, why would we still want them to be conforming? If we say that they are *not* conforming, we also say that things like the "supply chain attack" scenario/example described in P3829 is something that should never happen. Wouldn't that be a good thing?
Cheers,
Timur
Received on 2025-10-21 07:36:14
