On Wed, Jun 19, 2024 at 08:07:09PM +0000, Paul Floyd via Valgrind-users wrote: > On 19-06-24 08:15, Thomas Wollenzin wrote: > >Thanks for the hint, Sean. > >While that might work perfectly fine, I'm personally not a big fan > >of these types of tools. They're fine for proofing a theory but > >shouldn't be used to 'cover up' developer mistakes. Code should be > >written as solidly as possible. > > Read more about the proposal here > > https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2022/p2723r0.html > > I'm fairly certain that things like this will be part of C++ in the > next 5 years or so. That won't be using this option directly, more > likely part of a 'profiles' feature.
Interesting proposal. I notice they mention that valgrind memcheck will no longer be able to detect use of uninitialized variables anymore: Making all automatic variables explicitly zero means that developers will come to rely on it. The current status-quo forces developers to express intent, and new code might decide not to do so and simply use the zero that they know to be there. This would then make it impossible to distinguish "purposeful use of the uninitialized zero" from "accidental use of the uninitialized zero". Tools such as memory sanitizers and valgrind would therefore be unable to diagnose correctness issues (but we would have removed the security issues). It should still be best practice to only assign a value to a variable when this value is meaningful, and only use an "uninitialized" value when meaning has been give to it. I wonder if there would be some implementation so that we can detect the zeroing is part of this automatic variable initialization and then still mark the storage as not defined. But I cannot think of one. It seems optimizatin of the code will make it indistinquisable from explicit initialization. Cheers, Mark _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
