Date: Mon, 10 Mar 2025 10:36:09 +0100
On 25/02/2025 12:45, Yongwei Wu via Std-Discussion wrote:
> Currently, Obj::scratch_buffer will contain indeterminate values. In
> C++26, will there be a way for it to opt out of the erroneous value
> initialization, sans requiring the user to change the client-side
> code?
I think there's a misunderstanding here: EB doesn't mandate that the
storage for an automatic variable gets initialized in any specific way.
It just changes the semantics of what happens if you read from an
uninitialized automatic variable (you get EB). The [[indeterminate]]
attribute restores the pre-C++26 semantics (you get UB).
Do you have a use case for always wanting UB instead of EB for
uninitialized reads of a non-static data member?
On the other hand: even in pre-C++26 modes, compilers have hardening
options that fill the storage for automatic variables with certain bit
patterns (such as -ftrivial-auto-var-init), and also have
compiler-specific attributes to opt-out in case this filling gets too
expensive (such as [[gnu::uninitialized]]). For certain use cases it may
make sense to disable such filling, and to do so in a centralized manner
(by applying the attribute to a class, or a constructor, or a data
member, etc., that's open for debate).
My 2 c,
--
Giuseppe D'Angelo
> Currently, Obj::scratch_buffer will contain indeterminate values. In
> C++26, will there be a way for it to opt out of the erroneous value
> initialization, sans requiring the user to change the client-side
> code?
I think there's a misunderstanding here: EB doesn't mandate that the
storage for an automatic variable gets initialized in any specific way.
It just changes the semantics of what happens if you read from an
uninitialized automatic variable (you get EB). The [[indeterminate]]
attribute restores the pre-C++26 semantics (you get UB).
Do you have a use case for always wanting UB instead of EB for
uninitialized reads of a non-static data member?
On the other hand: even in pre-C++26 modes, compilers have hardening
options that fill the storage for automatic variables with certain bit
patterns (such as -ftrivial-auto-var-init), and also have
compiler-specific attributes to opt-out in case this filling gets too
expensive (such as [[gnu::uninitialized]]). For certain use cases it may
make sense to disable such filling, and to do so in a centralized manner
(by applying the attribute to a class, or a constructor, or a data
member, etc., that's open for debate).
My 2 c,
--
Giuseppe D'Angelo
Received on 2025-03-10 09:36:20