220 11499 article Path: news.gmane.org!not-for-mail From: Michael McLaughlin Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Controversy and debate: Uninitialized variables by default is a bug Date: Tue, 17 Jun 2014 20:33:12 -0400 Lines: 415 Approved: news@gmane.org Message-ID: References: <60caa4ef-b32d-40fe-97b6-8918fbb2bd51@isocpp.org> <1673959.6KvSiLfFrv@tjmaciei-mobl4> <438c8d34-c59d-42b2-ac81-6053f3a15e92@isocpp.org> <2386503.Orhs6aKSHF@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf301b67b3c82be704fc1167a1 X-Trace: ger.gmane.org 1403051602 31055 80.91.229.3 (18 Jun 2014 00:33:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Jun 2014 00:33:22 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCX3XKVL7MKRBSN4QOOQKGQEAS5YJ3I@isocpp.org Wed Jun 18 02:33:15 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f69.google.com ([209.85.220.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wx3oQ-0007J5-KK for gclcip-std-proposals@m.gmane.org; Wed, 18 Jun 2014 02:33:15 +0200 Original-Received: by mail-pa0-f69.google.com with SMTP id kq14sf542049pab.0 for ; Tue, 17 Jun 2014 17:33:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=7T3iiHzTnyL8K+MX5GmlKDsZRlqcl8sfzK+iIvk8Chk=; b=cSDUEkfH6S/+LvdknlTkJ2HA1m8ofhPPMs9qa6slKYmL6J4qQUJZrfVcY3cA2BfkNn 5ZVZ7wTZAErbtbcQzsWTGsCon7cyOnA++zoBvIXzuVhOAw5QYX2zIoTVWW0vklC3VYkQ jdorju+WBkkue0GcsHlZwzd1HwQM2kq83Vk2KQazWqdMfWejtPP3G7Wkf/Bdb/oZRbyV BvCdKYGUMsGr5NZ0WmpUMro7XiWG9Vf1jh4quEf/l4CsFHtjlWR/deX6YxVQLY56EyqW xHgJWpawIi/Dn92SErzEwm3BhrhpwVyVtsG1JN4j/f72Wuw3kjMcHAca4DyjfeT8G4nt oytQ== X-Gm-Message-State: ALoCoQke6mOgYOxpPx6TkTB0/fQ6LKYw0gxHnrn15cCmMJdODRLDQHYJCLIGqvbxG8D0KrtOVlSt X-Received: by 10.66.156.2 with SMTP id wa2mr3195303pab.0.1403051593556; Tue, 17 Jun 2014 17:33:13 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.36.5 with SMTP id m5ls1778452igj.20.canary; Tue, 17 Jun 2014 17:33:12 -0700 (PDT) X-Received: by 10.42.25.19 with SMTP id y19mr31171155icb.45.1403051592819; Tue, 17 Jun 2014 17:33:12 -0700 (PDT) Original-Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [2607:f8b0:4001:c05::22f]) by mx.google.com with ESMTPS id l15si1922508igt.45.2014.06.17.17.33.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 17:33:12 -0700 (PDT) Received-SPF: pass (google.com: domain of mikebmcl@gmail.com designates 2607:f8b0:4001:c05::22f as permitted sender) client-ip=2607:f8b0:4001:c05::22f; Original-Received: by mail-ig0-f175.google.com with SMTP id h3so364426igd.2 for ; Tue, 17 Jun 2014 17:33:12 -0700 (PDT) X-Received: by 10.42.122.208 with SMTP id o16mr29472237icr.39.1403051592656; Tue, 17 Jun 2014 17:33:12 -0700 (PDT) Original-Received: by 10.64.250.230 with HTTP; Tue, 17 Jun 2014 17:33:12 -0700 (PDT) In-Reply-To: X-Original-Sender: mikebmcl@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of mikebmcl@gmail.com designates 2607:f8b0:4001:c05::22f as permitted sender) smtp.mail=mikebmcl@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:11499 Archived-At: --20cf301b67b3c82be704fc1167a1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think there's a way forward here that could improve things without changing the status quo. Consider the following hypothetical pseudo-proposal: - Add a syntax to explicitly specify that a variable should not be initialized (e.g. "int x =3D void; float z[100000] =3D void;" - why " =3D void"? void is already reserved and can't legally be used like that now so it seems like a good candidate). - Add some language to clearly specify that the existing C/C++03/C++11/C++14 behavior (i.e. "int x; float z[100000];" means uninitialized) is the default behavior. Then state that a conforming implementation can give users the option to explicitly opt-in to a different behavior. The intent being that compiler switches (or defining some macro or whatever the implementer wants to do) can change that, but that the user doesn't need to do anything different to keep the existing uninitialized behavior. I believe that those changes would be enough to give compiler vendors the leeway needed to do several things via switches (or macro definitions, etc.). First, they could add a behavior where the absence of the explicit uninitialized syntax and no compiler-provable initialization produces a compilation error. Second, they could do the same thing except instead of an error diagnostic it emits a warning and produces zero/nullptr initialization. Third, they could do the same thing as the second option except with no diagnostic. Q. Why do we need these changes? Can't implementers do this now? A. Not with standard C++. Without a legal syntax for explicitly specifying that a variable should not be initialized, users have no standard way to let the compiler know that a variable is intentionally uninitialized. The fallback then is an implementation-defined attribute or some non-standard behavior (e.g. a language extension). Q. What's wrong with implementation-defined attributes? A. Nothing for features that aren't ripe for standardization. But since this involves vendor-neutral behavior, then unless every implementer uses the same attribute in exactly the same way, the code will start to get ugly and unreadable pretty quickly with all of the #ifdefs (not to mention that there's no guarantee that they'd all use attributes and no guarantee that things would remain stable from version to version so you'd probably have #ifdefs even if they did just happen to use the same syntax). From my perspective as a developer, working through an old codebase and adding in " =3D void" where appropriate is time consuming but easy enough. Adding a hug= e block of conditional macros to every intentionally uninitialized variable and maintaining them over the years as new and different compilers are used to compile that code promises to be a nightmare. Q. So what about using a standardized attribute? A. I think the " =3D void" syntax is nicer, but if using an attribute (or something else that can be standardized) instead is what it would take to get a consensus then I'm not opposed to it. Another benefit to using " = =3D void" is that maybe the ISO C folks would be willing to consider that as an addition to C (for substantially the same reasons as given here). I don't know what they'd make of a proposal that required attributes. [ Note: If both the ISO C and ISO C++ committees agreed to add explicit uninitialized variables and they both adopted the same syntax, then arguments against this due to C-compatibility issues go away. Then it's just a matter of legacy code and the maintainers of that code would have to opt-in to this behavior such that even that shouldn't be a problem. They can either adopt it at their own pace (and maybe eliminate some unknown bugs along the way) or stick with classic syntax and ignore this feature. -- end note ] Q. But you aren't actually proposing a standardized way to eliminate unintentionally uninitialized variables are you? A. You caught me; my proposal doesn't do that. It proposes a syntax for explicit uninitialized variables along with some language that gives implementers the leeway they need to create better tools that are still standards-conformant. I like the three hypothetical behaviors I described earlier (compilation error; warning + zero initialization; and zero initialization without a diagnostic) and hope that implementers would provide all three. Indeed a formal proposal might even include language in a Note section that strongly encouraged implementers to provide users a way to get each of those three behaviors. But proposing standardizing compiler switches (or any of the other ways I can think of to actually produce any of those behaviors while leaving the default behavior alone)? What I propose above involves a change to the language (whether it's " =3D void" or a newly standardized attribute or whatever). That change might break C compatibility in some way that can't be coded around (though I'm not sure that it would since it's opt-in syntax that lets implementers enable opt-in behavior). Even without the possible break with C, it's poking a hornet's nest. I leave it to someone braver than me to propose standardizing compiler switches. Q. If it doesn't propose eliminating unintentionally uninitialized variables, why bother with it at all? A. Regardless of whether implementers make use of it to help eliminate unintentionally uninitialized variables, I think there is merit to letting programmers denote that a variable is intentionally uninitialized. To me the statement "int x =3D void;" expresses a programmer's intent in a way th= at "int x;" does not. As well, when code consistently uses "int x =3D void;" then seeing "double y;" is a pretty clear sign that the code involving 'y' bears closer scrutiny. In summary, eliminating the default uninitialized behavior seems to be impractical for the foreseeable future. This alternative gives us a chance to let programmers express their intent more clearly. It also gives implementers (by virtue of the opt-in clause) the ability to provide standards-conformant tools that will help programmers find and eliminate uninitialized variable bugs, while still respecting the programmer's wishes to not have, e.g., an array of fifty thousand floats be automatically zero-initialized. Further, if this became part of C++, it's possible that the Committee could eventually consider deprecating the current initialization behavior with an aim towards eventually removing it in favor of requiring that programmers use the " =3D void" syntax when they actually desire an uninitialized variable. Not that they will or even should. But this proposal would make that something which could eventually be practical. In the meantime it would give programmers an elegant, concise way to make their code more expressive. ;;; If it wouldn't be a clear waste of everyone's time, I'm willing to turn that into a formal proposal that can be considered seriously. I wish I had been able to make it to Rapperswil so I could float it around a bit there to get a sense of whether it has any chance. If anyone sees any serious flaws in it please do let me know. If you think the idea has merit, please feel free to let me know that as well (whether on-list or off-). Thanks! -Mike On Tue, Jun 17, 2014 at 1:39 PM, Klaim - Jo=C3=ABl Lamotte wrote: > > > > On Tue, Jun 17, 2014 at 6:59 PM, Thiago Macieira > wrote: > >> Em ter 17 jun 2014, =C3=A0s 09:27:35, Matthew Fioravante escreveu: >> > If you believe this to impact performance, and want to be unsafe (in t= he >> > case that someone adds and passes in a new enum value tomorrow to your >> > library), you can say int x =3D void here. >> >> If we were designing a new language with no existing codebase, I'd >> definitely >> agree with you. >> >> Changing C++ some 40 years after the fact (if we can include the C >> legacy) is >> a no-go. >> >> > Actually, I think such a change (force the user to specify initialization > or not) could be made if > there was a big amount of uncontroversial data on issues that the current > rules make easy to get into. > Also, if there is a way to easily point these issues once the change is i= n > place, then why not? > > Basically, I don't think the initial proposal is a good idea, but > disallowing implicit uninitialization at all, and having an explicit way = to > specify uninitialization, would be good enough > for the compiler to point issues immediately, and would help code readers > too to understand the intent. > It appear to me to be more compatible with C++11 and previous C++ version= s > to do it that way. > > > -- > > --- > 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. > Visit this group at > http://groups.google.com/a/isocpp.org/group/std-proposals/. > --=20 ---=20 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 e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --20cf301b67b3c82be704fc1167a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think there's=C2=A0a way forward here that coul= d=C2=A0improve things without changing the status quo.
=C2=A0
Consider the following hypothetical pseudo-proposal:

<= /div>
-=C2=A0Add a syntax to explicitly specify that a variable should = not be initialized (e.g. "int x =3D void; float z[100000] =3D void;&qu= ot;=C2=A0- why " =3D void"?=C2=A0void is=C2=A0already reserved an= d can't legally be used like that now so it seems like a good candidate= ).
-=C2=A0Add some language=C2=A0to clearly=C2=A0specify that=C2=A0the ex= isting=C2=A0C/C++03/C++11/C++14=C2=A0behavior (i.e. "int x; float z[10= 0000];" means uninitialized)=C2=A0is the default behavior.=C2=A0Then s= tate=C2=A0that a conforming implementation can give users the option to exp= licitly opt-in to a different behavior. The intent being that compiler swit= ches (or defining some macro=C2=A0or whatever the implementer wants to do) = can change that, but that the user doesn't need to do anything differen= t to keep the existing uninitialized behavior.

I believe that those changes would be enough to give co= mpiler vendors the leeway needed to do several things via switches (or macr= o definitions, etc.). First, they could add a behavior where the absence of= the explicit uninitialized syntax and no compiler-provable initialization = produces a compilation error. Second, they could do the same thing except i= nstead of an error diagnostic it emits a warning and produces=C2=A0zero/nul= lptr initialization. Third, they could do the same thing as the second opti= on except with no diagnostic.
=C2=A0
Q. Why do we need these changes? Can't=C2=A0imple= menters do this now?
=C2=A0
A. Not with standard C++. W= ithout a legal syntax for explicitly specifying that a variable should not = be initialized, users have no standard=C2=A0way to let the compiler know th= at a variable is intentionally uninitialized. The fallback then is an imple= mentation-defined attribute or some=C2=A0non-standard behavior (e.g. a=C2= =A0language extension).
=C2=A0
=C2=A0
Q. What's wrong with implementat= ion-defined attributes?
=C2=A0
A. Nothing for features = that aren't ripe for standardization. But since this involves vendor-ne= utral behavior, then unless every implementer uses the same attribute in ex= actly the same way, the code will start to get ugly and unreadable pretty q= uickly with all of the #ifdefs (not to mention that there's no guarante= e that they'd all use attributes and no guarantee that things would=C2= =A0remain stable=C2=A0from version to version so you'd probably have #i= fdefs even if they did just happen to use the same syntax). From my perspec= tive as a developer,=C2=A0working through an old=C2=A0codebase and adding i= n " =3D void" where appropriate is time consuming but easy enough= .. Adding=C2=A0a huge block of conditional macros to every=C2=A0intentionall= y uninitialized=C2=A0variable and maintaining them over the years as new an= d different compilers are used to compile that code=C2=A0promises to be a n= ightmare.
=C2=A0
=C2=A0
Q. So what about using a standardize= d attribute?
=C2=A0
A. I think the " =3D void"= ; syntax is nicer, but if using an attribute (or something else that can be= standardized)=C2=A0instead=C2=A0is what it=C2=A0would take to=C2=A0get a c= onsensus then I'm not opposed to it. Another benefit to using " = =3D void" is that=C2=A0maybe the ISO C folks=C2=A0would be willing to = consider that as an addition to C (for substantially the same reasons as gi= ven here). I don't know what they'd make of a proposal that require= d attributes. [ Note: If both the ISO C and ISO C++ committees agreed to ad= d explicit uninitialized variables and they both=C2=A0adopted the same synt= ax, then arguments against this due to C-compatibility=C2=A0issues go away.= Then=C2=A0it's just a matter of legacy code and the maintainers of tha= t code would have to opt-in to this behavior such that even that shouldn= 9;t be a problem. They can either adopt it at their own pace (and maybe eli= minate some unknown bugs along the way) or stick with classic syntax and ig= nore this feature. -- end note ]
=C2=A0
=C2=A0
Q. But you aren't actually propo= sing a standardized way to eliminate unintentionally uninitialized variable= s are you?
=C2=A0
A. You caught me; my proposal doesn&#= 39;t do that. It proposes a=C2=A0syntax for explicit uninitialized variable= s along with some language that gives implementers the leeway they need to = create better tools that are still standards-conformant. I like the three h= ypothetical behaviors I described earlier (compilation error; warning + zer= o initialization; and zero initialization without a diagnostic) and hope th= at implementers would=C2=A0provide all three. Indeed a formal proposal migh= t even=C2=A0include language in a Note section=C2=A0that strongly encourage= d=C2=A0implementers to provide=C2=A0users a way to=C2=A0get each of those t= hree behaviors.=C2=A0But proposing standardizing compiler switches (or any = of the other ways I can think of to actually produce any of those behaviors= while leaving the default behavior alone)? What I=C2=A0propose above invol= ves a change to the language (whether it's " =3D void" or a n= ewly=C2=A0standardized attribute or whatever).=C2=A0That change=C2=A0might = break C compatibility in some way that can't be coded around (though I&= #39;m not sure that it would since it's opt-in syntax that lets impleme= nters enable opt-in behavior). Even without the possible break with C,=C2= =A0it's poking a hornet's nest. I leave it to someone braver than m= e=C2=A0to propose standardizing compiler switches.
=C2=A0
=C2=A0
Q. If it doesn't propose elimina= ting unintentionally uninitialized variables, why bother with it at all?
=C2=A0
A.=C2=A0Regardless of whether=C2=A0implementers ma= ke use of it=C2=A0to help=C2=A0eliminate unintentionally uninitialized vari= ables,=C2=A0I think there is merit to letting programmers denote that a var= iable is intentionally uninitialized. To me the statement "int x =3D v= oid;"=C2=A0expresses=C2=A0a programmer's=C2=A0intent in a way that= "int x;" does not. As well, when code consistently uses "in= t x =3D void;"=C2=A0then=C2=A0seeing=C2=A0"double y;" is a p= retty clear sign that the code involving 'y' bears closer scrutiny.=
=C2=A0
In summary, eliminating the default uninitialized beh= avior=C2=A0seems to be=C2=A0impractical for the foreseeable future. This al= ternative=C2=A0gives us a chance to let programmers express their intent mo= re clearly.=C2=A0It also gives implementers (by virtue of the opt-in clause= ) the ability to provide standards-conformant tools that will help programm= ers find and eliminate uninitialized variable bugs, while still respecting = the programmer's wishes to not have, e.g.,=C2=A0an array of fifty thous= and floats be automatically zero-initialized. Further, if=C2=A0this became = part of C++, it's possible that the Committee=C2=A0could=C2=A0eventuall= y consider deprecating the current initialization behavior with an aim towa= rds eventually removing it in favor of requiring that programmers use the &= quot; =3D void" syntax when they actually desire an uninitialized vari= able. Not that they will or even should. But=C2=A0this proposal=C2=A0would = make that something which could eventually be practical. In the meantime it= would give programmers an elegant, concise=C2=A0way to make their code mor= e expressive.
=C2=A0
;;;
=C2=A0
If it wouldn't be = a clear waste of everyone's time, I'm willing to turn that into a f= ormal proposal that can be considered seriously. I wish I had been able to = make it to Rapperswil so I could float it around a bit there to get a sense= of whether it has any chance. If anyone sees any serious flaws in it pleas= e do let me know. If you think the idea has merit, please feel free to let = me know that as well (whether on-list or off-).
=C2=A0
Thanks!
=C2=A0
-Mike
= =C2=A0



On Tue, Jun 17, 2014 at 1:39 PM, Kla= im - Jo=C3=ABl Lamotte <mjklaim@gmail.com> wrote:



On Tue, Jun 17, 2014 at 6:59 PM, Thiago Macieira <= ;thiago@macieira.o= rg> wrote:
Em ter 17 jun 2014, =C3=A0s 09:27:35, Matthew Fioravante e= screveu:
> If you believe this to impact performance, and want to be unsafe = (in the
> case that someone adds and passes in a new enum value tomorrow to your=
> library), you can say int x =3D void here.

If we were designing a new language with no existing codebase, I'= d definitely
agree with you.

Changing C++ some 40 years after the fact (if we can include the C legacy) = is
a no-go.


Actually, = I think such a change (force the user to specify initialization or not) cou= ld be made if
there was a=C2=A0big amount of uncontroversial data= on issues that the current rules make easy to get into.
Also, if there is a way to easily point these issues once the change i= s in place, then why not?

Basically, I don't t= hink the initial proposal is a good idea, but disallowing implicit uninitia= lization at all, and having an explicit way to specify=C2=A0uninitializatio= n, would be good enough
for the compiler to point issues immediately, and would help code read= ers too to understand the intent.=C2=A0
It appear to me to be mor= e compatible with C++11 and previous C++ versions to do it that way.
<= div>

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/gro= up/std-proposals/.

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--20cf301b67b3c82be704fc1167a1-- .