------=_Part_5484_405140664.1504545832391
Content-Type: multipart/alternative;
 boundary="----=_Part_5485_1558125423.1504545832391"

------=_Part_5485_1558125423.1504545832391
Content-Type: text/plain; charset="UTF-8"

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

--
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-proposals@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.

------=_Part_5485_1558125423.1504545832391
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>Given a container of som=
e scalars which would only later be filled with values (e.g. via some algor=
ithm), I often myself debating whether to either</div><div>1) Initialize th=
e container with zeros, so in case there&#39;s a bug and some element is fo=
rgotten, the resulting bug would probably be easier to analyzer than if the=
 element were just some garbage value; or,</div><div>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 catc=
h it.</div><div><br></div><div>I think it could be beneficial to be able to=
 do both 1 and 2. I&#39;m not sure through what mechanism, though.</div><di=
v><br></div><div>Does this resonate with anyone?</div><div><br></div><div>T=
hanks,</div><div>Dan</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3b4d73e1-47bc-4929-8f02-70eb84825dc4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3b4d73e1-47bc-4929-8f02-70eb84825dc4=
%40isocpp.org</a>.<br />

------=_Part_5485_1558125423.1504545832391--

------=_Part_5484_405140664.1504545832391--

.

--001a1149b46acede5e055860c512
Content-Type: text/plain; charset="UTF-8"

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.

On Mon, Sep 4, 2017 at 10:23 AM, Dan Raviv <dan.raviv@gmail.com> wrote:

> 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
>
> --
> 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-proposals@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
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3b4d73e1-47bc-4929-8f02-70eb84825dc4%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPuuy5ewiexjKRtskFE8OphY1yV73k-AMMcowRGPX0Rz5xcuEQ%40mail.gmail.com.

--001a1149b46acede5e055860c512
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This isn&#39;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, el=
se go submit a feature request to those analyzers. Changing the language is=
 completely unneeded to do this.</div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On Mon, Sep 4, 2017 at 10:23 AM, Dan Raviv <span dir=
=3D"ltr">&lt;<a href=3D"mailto:dan.raviv@gmail.com" target=3D"_blank">dan.r=
aviv@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div>Hi,</div><div><br></div><div>Given a container of some sc=
alars which would only later be filled with values (e.g. via some algorithm=
), I often myself debating whether to either</div><div>1) Initialize the co=
ntainer with zeros, so in case there&#39;s a bug and some element is forgot=
ten, the resulting bug would probably be easier to analyzer than if the ele=
ment were just some garbage value; or,</div><div>2) Leave the container uni=
nitialized until it is (hopefully sooner rather than) later filled with val=
ues, so if some element is uninitialized the static analyzer could catch it=
..</div><div><br></div><div>I think it could be beneficial to be able to do =
both 1 and 2. I&#39;m not sure through what mechanism, though.</div><div><b=
r></div><div>Does this resonate with anyone?</div><div><br></div><div>Thank=
s,</div><div>Dan</div></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3b4d73e1-47bc-4929-8f02-70eb84825dc4%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/3b4d=
73e1-47bc-4929-<wbr>8f02-70eb84825dc4%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPuuy5ewiexjKRtskFE8OphY1yV73k-AMMco=
wRGPX0Rz5xcuEQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPuuy5ewiexjKRts=
kFE8OphY1yV73k-AMMcowRGPX0Rz5xcuEQ%40mail.gmail.com</a>.<br />

--001a1149b46acede5e055860c512--

.

On Monday, 4 September 2017 14:23:52 -03 Dan Raviv wrote:
> 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?

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

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/167268544.sH1yzsBimG%40tjmaciei-mobl1.

.

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

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/abf8bb86-4b92-8551-d765-56fc888c56ac%40gmail.com.

.