Idea: Allow initializing variables but let static analyzer consider them uninitialized

[Dan Raviv]

Hi,

Given a container of some scalars which would only later be filled with values (e.g. via some algorithm), I often myself debating whether to either

1) Initialize the container with zeros, so in case there's a bug and some element is forgotten, the resulting bug would probably be easier to analyzer than if the element were just some garbage value; or,

2) Leave the container uninitialized until it is (hopefully sooner rather than) later filled with values, so if some element is uninitialized the static analyzer could catch it.

I think it could be beneficial to be able to do both 1 and 2. I'm not sure through what mechanism, though.

Does this resonate with anyone?

Thanks,

Dan

[Justin Bassett]

This isn't a change to the language at all. This is a feature request on the static analyzers you are using. You should probably look to see if there is such a feature already in the analyzers you use, else go submit a feature request to those analyzers. Changing the language is completely unneeded to do this.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3b4d73e1-47bc-4929-8f02-70eb84825dc4%40isocpp.org.

[Thiago Macieira]

Maybe you want the VALGRIND_MAKE_MEM_UNDEFINED macro from valgrind/memcheck.h.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Matthew Woehlke]

On 2017-09-04 13:52, Justin Bassett wrote:
> This isn't a change to the language at all. This is a feature request on
> the static analyzers you are using. You should probably look to see if
> there is such a feature already in the analyzers you use, else go submit a
> feature request to those analyzers. Changing the language is completely
> unneeded to do this.

This was exactly my knee-jerk reaction as well.

*Possibly* this would make sense as an attribute (I'd need to see usage
examples to have a better feeling if an attribute is practical), but
even so, I think it makes sense to start as a vendor-specific extension.
If that happens, and is found to be useful and to work well, perhaps at
that point it may be worth proposing to elevate to a standard attribute.

--
Matthew