220 11489 article Path: news.gmane.org!not-for-mail From: Jim Porter Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Controversy and debate: Uninitialized variables by default is a bug Date: Tue, 17 Jun 2014 09:20:13 -0700 (PDT) Lines: 121 Approved: news@gmane.org Message-ID: References: <60caa4ef-b32d-40fe-97b6-8918fbb2bd51@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_188_12382666.1403022013776" X-Trace: ger.gmane.org 1403022025 23908 80.91.229.3 (17 Jun 2014 16:20:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Jun 2014 16:20:25 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDYZZG6PQYFRBPWVQGOQKGQEYC35KKA@isocpp.org Tue Jun 17 18:20:18 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f200.google.com ([209.85.223.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Www7M-0002Re-8q for gclcip-std-proposals@m.gmane.org; Tue, 17 Jun 2014 18:20:16 +0200 Original-Received: by mail-ie0-f200.google.com with SMTP id tr6sf43140738ieb.3 for ; Tue, 17 Jun 2014 09:20:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=fkqJi//48xKzkZ4oF/3kSQqJo7V9pnfX2lyIBfJSgUQ=; b=E2e9m4tMNEO2wvtvIZZB4jMABzB28kZKFVKoGuu9c7xnaacxuYug7Qik22PONlmqQL puHxuI1PjKL6JSkUs6vGkVFd7H3oT7z3W7t8DPMSnqSL7BQOKUyLplsaWAptXyGmNrpk Qg8J1sYk3rmyfotE/fcQC1BCXoPEMs5j9snIhSa7VZ6Rl41d8h6eyEwANrvbyAcUvX61 BL0f7naIKnooROgBug808OxYdKXXsNKLwbBjw+YcbLUZvWCFezMoDUeJgpDT1G3RBhxC m9ZdgiP2gpGYQcQq3LniiX7TCvLTzeMGXWK/HS6dpFsuvBctSzlG56rXFlMD4HGy/GD3 Bpmw== X-Gm-Message-State: ALoCoQmNfjNTLBmF5g5b2wSNiC78fntVqolWf8z5YnBcj0RezXvqzDmoVAyLd6Y/6mKlWrJbmyUL X-Received: by 10.182.250.229 with SMTP id zf5mr451446obc.4.1403022015318; Tue, 17 Jun 2014 09:20:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.138.69 with SMTP id qo5ls2056722obb.34.gmail; Tue, 17 Jun 2014 09:20:14 -0700 (PDT) X-Received: by 10.182.98.136 with SMTP id ei8mr12179obb.39.1403022014445; Tue, 17 Jun 2014 09:20:14 -0700 (PDT) In-Reply-To: X-Original-Sender: jvp4846@g.rit.edu 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:11489 Archived-At: ------=_Part_188_12382666.1403022013776 Content-Type: text/plain; charset=UTF-8 On Tuesday, June 17, 2014 10:58:55 AM UTC-5, Nevin ":-)" Liber wrote: > > On 17 June 2014 17:49, Matthew Fioravante > wrote: > >> Please now, convince if you can why this is a bad idea. >> > > Because IMO the correct answer is that the default should be for requiring > users to explicitly initialize the variable, and have a way to mark it the > few times they want an uninitialized variable. All initializing to zero > does is move the problem from something that static analyzers can catch to > something they can't. > I agree. I strongly believe that is there is a default behavior for variable declarations with no initializer, it shouldn't initialize the variable at all. However, I'm not convinced that there *needs* to be a default case except for maintaining compatibility. > Plus, that ship has sailed with C a long, long time ago... > I think it would be reasonable to add the option explicit-non-initialization to the standard, e.g. int foo; // doesn't initialize int foo = __no_init__; // doesn't initialize int foo = 0; // initializes (I'm avoiding picking a real syntax for this for now.) This lets people be explicit rather than implicit when they don't want to initialize a variable at declaration, which would then allow compilers to emit a warning (not an error!) if you don't do this. However, I'd hope that compiler authors would only emit the warning when their static analyzer couldn't prove that you always set the variable anyway. That is, the following shouldn't warn: int func() { int foo; if(something) foo = 1; else foo = 2; } - Jim -- --- 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/. ------=_Part_188_12382666.1403022013776 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tuesday, June 17, 2014 10:58:55 AM UTC-5, Nevin ":-)" L= iber wrote:
On 17 June 2014 17:49, Matthew Fioravante <fmatth...@gmail.com> wrote:
Please now, convince if you= can why this is a bad idea.

Because = IMO the correct answer is that the default should be for requiring users to= explicitly initialize the variable, and have a way to mark it the few time= s they want an uninitialized variable.  All initializing to zero does = is move the problem from something that static analyzers can catch to somet= hing they can't.

I agree. I st= rongly believe that is there is a default behavior for variable declaration= s with no initializer, it shouldn't initialize the variable at all. However= , I'm not convinced that there *needs* to be a default case except for main= taining compatibility.
 
Plus, that ship has sailed with C a long, long time ago...<= /div>

I think it would be reasonable= to add the option explicit-non-initialization to the standard, e.g.
  int foo; // doesn't initialize
  int foo =3D __no_init__; /= / doesn't initialize
  int foo =3D 0; // initializes

(I'm av= oiding picking a real syntax for this for now.) This lets people be explici= t rather than implicit when they don't want to initialize a variable at dec= laration, which would then allow compilers to emit a warning (not an error!= ) if you don't do this. However, I'd hope that compiler authors would only = emit the warning when their static analyzer couldn't prove that you always = set the variable anyway. That is, the following shouldn't warn:

&nbs= p; int func() {
    int foo;
    if(som= ething)
      foo =3D 1;
    = else
      foo =3D 2;
  }

- Jim<= br>

--

---
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>.
------=_Part_188_12382666.1403022013776-- .