220 11479 article Path: news.gmane.org!not-for-mail From: Jonathan Coe Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Controversy and debate: Uninitialized variables by default is a bug Date: Tue, 17 Jun 2014 17:53:33 +0200 Lines: 341 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=089e011615fc6348cb04fc0a25ff X-Trace: ger.gmane.org 1403020423 2774 80.91.229.3 (17 Jun 2014 15:53:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Jun 2014 15:53:43 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBC2JVFPBRAHBB7WIQGOQKGQEKUCU36Q@isocpp.org Tue Jun 17 17:53:36 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f199.google.com ([209.85.223.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WwvhX-0002ZN-Ny for gclcip-std-proposals@m.gmane.org; Tue, 17 Jun 2014 17:53:36 +0200 Original-Received: by mail-ie0-f199.google.com with SMTP id rd18sf42939193iec.6 for ; Tue, 17 Jun 2014 08:53:34 -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:sender: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=z1Sj7W4A2M7UOu7J1F01mgCeMcyU5eJtXt1R0iga9zI=; b=Jnj+P1jheThVk5bvcptz8enO4QyOmJxBagblvQjDxwhDbOGDjrmursLze5T/ItOyau I8zGux4r1j8K/LKa+HGcFzgY+eJrsHGrH0ihsIsUnAeNtcED1Hhkxi2vkYglb7XPcMJO fFi7kGzrVFXUko47ZXM31AImzgDWnREib/ohji4XjBEwUwZrxL5mC78LGjZTy2UEAfnQ TaPf1WEIp6KdpKtgAm/voiPyZk16oCIiOtCwX9FUZyEZbTZLg6sI1jWy2xU2sIaylVuO QeGZ3e3Or4tDQpUp/ee1aNU9b6Mj/OhsbWDWhejUdnb6HBz/USEUVaXGnTq3vngiBU6r NiuQ== X-Gm-Message-State: ALoCoQnlejGgNKZnkwzbSH39TcjpwXWvo/nQeWODoC36pmVjmYWhHnpw3bsepv04GAEYcoVu4SHt X-Received: by 10.182.128.234 with SMTP id nr10mr1015888obb.0.1403020414819; Tue, 17 Jun 2014 08:53:34 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.109.247 with SMTP id l110ls4699392qgf.90.gmail; Tue, 17 Jun 2014 08:53:34 -0700 (PDT) X-Received: by 10.236.147.74 with SMTP id s50mr45555774yhj.108.1403020414134; Tue, 17 Jun 2014 08:53:34 -0700 (PDT) Original-Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [2607:f8b0:4002:c07::22e]) by mx.google.com with ESMTPS id g9si21591668yhe.199.2014.06.17.08.53.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 08:53:34 -0700 (PDT) Received-SPF: pass (google.com: domain of jonathanbcoe@gmail.com designates 2607:f8b0:4002:c07::22e as permitted sender) client-ip=2607:f8b0:4002:c07::22e; Original-Received: by mail-yk0-f174.google.com with SMTP id 19so5390443ykq.19 for ; Tue, 17 Jun 2014 08:53:34 -0700 (PDT) X-Received: by 10.236.45.10 with SMTP id o10mr45392956yhb.49.1403020413976; Tue, 17 Jun 2014 08:53:33 -0700 (PDT) Original-Sender: jonathanbcoe@gmail.com Original-Received: by 10.170.62.214 with HTTP; Tue, 17 Jun 2014 08:53:33 -0700 (PDT) In-Reply-To: <60caa4ef-b32d-40fe-97b6-8918fbb2bd51@isocpp.org> X-Original-Sender: jonathanbcoe@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of jonathanbcoe@gmail.com designates 2607:f8b0:4002:c07::22e as permitted sender) smtp.mail=jonathanbcoe@gmail.com; dkim=pass header.i=@gmail.com; dmarc=fail (p=NONE dis=NONE) header.from=me.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:11479 Archived-At: --089e011615fc6348cb04fc0a25ff Content-Type: text/plain; charset=UTF-8 Sometimes (in embedded systems for instance) initialization cost is considered to be significant. C++ generally follows the philosophy that you only pay for what you need. User- or library-defined types can force primitives to be initialized or value initialize them. for instance: http://www.boost.org/doc/libs/1_55_0/libs/utility/value_init.htm Regards, Jon On 17 June 2014 17:49, Matthew Fioravante wrote: > This is going to be controversial, but lets get into it. > > The fact that `int x;` creates an uninitialized integer instead of a > default initialized one is completely wrong. I consider it a major defect > in the language, a bug in the standard. > > One of my favorite C++11 API's is the atomic API. The reason is that it > does the right thing when it comes to correctness vs speed. By default, the > path of least resistance is to have everything sequentially consistent > which is the safest but also slowest memory ordering. If you know what > you're doing and need some speed, you can opt to use less safe orderings. > Even better, every use of the less safe ordering is tagged right there in > the source code (without a comment)! It really doesn't get much better than > that in terms of API design. It follows Scott Meyers maxim of "Making > interfaces easy to use correctly and hard to use incorrectly" perfectly. > > Initialization in C++ is the exact opposite of this. The easiest thing to > do is write bugs by forgetting to initialize things. How many of you have > spent long debugging sessions only to track the source to an uninitialized > variable? Not only that, but initialization in C++ is a horrible mess. lets > look at the list: > > Default initialization > Value Initialization > Copy Initialization > Direct Initialization > Aggregate Initialization > List initialization > Reference Initialization > Constant Initialization > > Do you know by memory how all of those work and their gotchas? I sure as > hell don't and I pity the novice developer who tries. Do we need this level > of complexity? > > Here is a sketch one possible way we could solve this problem: > > int x; //<-default initialized to 0 > int x = void; //<-uninitialized, I know what I'm doing > volatile int x; //<-uninitialized, because we can't introduce > additional writes to volatile variables or break existing device driver > code. > > Like the atomic API, the default action is the safe action, with options > to remove the restraints should you need it. > What I'm suggesting is that everything be initialized by default. And yes > that means all legacy code that flips the switch to use the next version of > the C++ language. If someone has a compelling performance argument for > leaving something uninitialized, the = void syntax is there for them. > > What are the advantages: > 1) Safe by default, if someone does a statistical survey, I'm confident > that after this change the average amount of time spent debugging C++ code > will go down. > 2) Dangerous places are marked (=void) as such, bringing attention and > carefully scrutiny by the person reading code. > 3) Less boilerplate code. Particularly with constructors I don't have to > write a bunch of stupid initialization code for my ints, floats, and > pointers. > 4) Initialization behavior matches static and global variables. One less > "except when" for Herb Sutter to write about in GotW. > > Counter arguments: > 1) This will slow down everyone's programs! > > No it won't. Compilers have been doing something called constant > propagation for over 20 years. > > That is, this code: > > int x = 0; > x = 1; > > Will be optimized to this: > int x = 1; > > 2) This will break C compatibility! > > No it won't. extern "C" code will still have the old behavior. There is no > C breakage here. The data being passed to and from C code is still the > same, regardless of whether or not it was initialized by the compiler. > > 3) Why do we need this? Compilers, static checkers, and debugging tools > can detect uninitialized use! > > Not always, and these tools are not always available. For example valgrind > is unusable on large resource consuming code bases. Also, even if there is > a tool why am I wasting my time checking this crap? I'd rather not be able > to easily write these bugs in the first place. Fix this and one *major* > class of bugs in C++ go away forever. > > 4) It will break legacy code! > > In some cases yes, but lets take a deeper look at the possibilities here: > > There are legacy code bases with real uninitialized variable bugs in them > today. Your company probably has 1 or 2 in their large code base and > miraculously its still working fine. If all of the sudden these things get > fixed, it may change the behavior of your program, causing a "bug" in the > sense that production is now operating differently. What used to be > undefined behavior just got defined. I don't see this as a huge problem. If > you have bugs in your code they need to be fixed. Also I do not believe > this is a good enough reason to continue the subpar status quo forever. > > Then there may be other cases, for example some kind of strange embedded > code or device drivers. Perhaps you instantiate an object over top of a > hardware memory address. If you are doing this, you are probably also > marking your variables as volatile, and that as I proposed above is still > uninitialized so you won't be affected. > > Maybe you're doing something really funky like putting your call stack on > some special memory, and default initialization will cause additional > writes which will cause your program to fail. If you're doing this kind of > crazy low level stuff, then you should know enough to be able to fix your > code. Also you will be now annotating these instances with = void or > volatile and that has the additional benefit of saying in your code, > without a comment "*hey I'm doing some funny stuff here with > initialization*". > > 5) I'm so good I don't write these kinds of bugs > > Congratulations, good job. Your colleagues however do write these kind of > bugs and will continue to do so until the end of time. Sometimes you may > even get to debug for them. > > I really enjoy C++, for all of its warts. I believe unlike other languages > which come and go, C++ has staying power and will be around and growing for > a long time. C++ is the fastest and most versatile language on the planet. > I don't see everyone jumping ship anytime soon for a complete rewrite > language like D (sorry Andrei). We're stuck with C++, so lets make it a > better language. > > Doing something like this would be huge. It would require a lot of > analysis to get right. My simple idea of =void (inspired from D, thanks > Andrei) may not work in all cases and will need to be fleshed out further. > > Please now, convince if you can why this is a bad idea. Why should we > continue to inflict wasted hours of debugging sessions for these kinds of > silly easy to write bugs on the future of C++? Can you think of any > possible reason uninitialized by default is good other than "maintaining > legacy code". > > > > -- > > --- > 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/. > -- --- 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/. --089e011615fc6348cb04fc0a25ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sometimes (in embedded systems for instance) initializatio= n cost is considered to be significant. C++ generally follows the philosoph= y that you only pay for what you need. User- or library-defined types can f= orce primitives to be initialized or value initialize them.


Regards,
<= br>
Jon


On 17 June 2014 17:49, Matthew Fioravante &l= t;fmatthew5876@= gmail.com> wrote:
This is going to be controv= ersial, but lets get into it.

The fact that `int x;` creates an unin= itialized integer instead of a default initialized one is completely wrong.= I consider it a major defect in the language, a bug in the standard.

One of my favorite C++11 API's is the atomic API. The reason is tha= t it does the right thing when it comes to correctness vs speed. By default= , the path of least resistance is to have everything sequentially consisten= t which is the safest but also slowest memory ordering. If you know what yo= u're doing and need some speed, you can opt to use less safe orderings.= Even better, every use of the less safe ordering is tagged right there in = the source code (without a comment)! It really doesn't get much better = than that in terms of API design. It follows Scott Meyers maxim of "Ma= king interfaces easy to use correctly and hard to use incorrectly" per= fectly.

Initialization in C++ is the exact opposite of this. The easiest thing = to do is write bugs by forgetting to initialize things. How many of you hav= e spent long debugging sessions only to track the source to an uninitialize= d variable? Not only that, but initialization in C++ is a horrible mess. le= ts look at the list:

Default initialization
Value Initialization
Copy InitializationDirect Initialization
Aggregate Initialization
List initialization<= br>Reference Initialization
Constant Initialization

Do you know b= y memory how all of those work and their gotchas? I sure as hell don't = and I pity the novice developer who tries. Do we need this level of complex= ity?

Here is a sketch one possible way we could solve this problem:

= =C2=A0=C2=A0=C2=A0 int x; //<-default initialized to 0
=C2=A0=C2=A0= =C2=A0 int x =3D void; //<-uninitialized, I know what I'm doing
= =C2=A0=C2=A0=C2=A0 volatile int x; //<-uninitialized, because we can'= ;t introduce additional writes to volatile variables or break existing devi= ce driver code.

Like the atomic API, the default action is the safe action, with option= s to remove the restraints should you need it.
What I'm suggesting i= s that everything be initialized by default. And yes that means all legacy = code that flips the switch to use the next version of the C++ language. If = someone has a compelling performance argument for leaving something uniniti= alized, the =3D void syntax is there for them.

What are the advantages:
1) Safe by default, if someone does a stati= stical survey, I'm confident that after this change the average amount = of time spent debugging C++ code will go down.
2) Dangerous places are m= arked (=3Dvoid) as such, bringing attention and carefully scrutiny by the p= erson reading code.
3) Less boilerplate code. Particularly with constructors I don't have t= o write a bunch of stupid initialization code for my ints, floats, and poin= ters.
4) Initialization behavior matches static and global variables. On= e less "except when" for Herb Sutter to write about in GotW.

Counter arguments:
1) This will slow down everyone's programs!
No it won't. Compilers have been doing something called constant = propagation for over 20 years.

That is, this code:

=C2=A0=C2= =A0=C2=A0 int x =3D 0;
=C2=A0=C2=A0=C2=A0 x =3D 1;

Will be optimized to this:
=C2=A0=C2= =A0=C2=A0 int x =3D 1;

2) This will break C compatibility!

No= it won't. extern "C" code will still have the old behavior. = There is no C breakage here. The data being passed to and from C code is st= ill the same, regardless of whether or not it was initialized by the compil= er.

3) Why do we need this? Compilers, static checkers, and debugging tools= can detect uninitialized use!

Not always, and these tools are not a= lways available. For example valgrind is unusable on large resource consumi= ng code bases. Also, even if there is a tool why am I wasting my time check= ing this crap? I'd rather not be able to easily write these bugs in the= first place. Fix this and one major class of bugs in C++ go away fo= rever.

4) It will break legacy code!

In some cases yes, but lets take a= deeper look at the possibilities here:

There are legacy code bases = with real uninitialized variable bugs in them today. Your company probably = has 1 or 2 in their large code base and miraculously its still working fine= .. If all of the sudden these things get fixed, it may change the behavior o= f your program, causing a "bug" in the sense that production is n= ow operating differently. What used to be undefined behavior just got defin= ed. I don't see this as a huge problem. If you have bugs in your code t= hey need to be fixed. Also I do not believe this is a good enough reason to= continue the subpar status quo forever.

Then there may be other cases, for example some kind of strange embedde= d code or device drivers. Perhaps you instantiate an object over top of a h= ardware memory address. If you are doing this, you are probably also markin= g your variables as volatile, and that as I proposed above is still uniniti= alized so you won't be affected.

Maybe you're doing something really funky like putting your call st= ack on some special memory, and default initialization will cause additiona= l writes which will cause your program to fail.=C2=A0 If you're doing t= his kind of crazy low level stuff, then you should know enough to be able t= o fix your code. Also you will be now annotating these instances with =3D v= oid or volatile and that has the additional benefit of saying in your code,= without a comment "hey I'm doing some funny stuff here with in= itialization".

5) I'm so good I don't write these kinds of bugs

Congrat= ulations, good job. Your colleagues however do write these kind of bugs and= will continue to do so until the end of time. Sometimes you may even get t= o debug for them.

I really enjoy C++, for all of its warts. I believe unlike other langua= ges which come and go, C++ has staying power and will be around and growing= for a long time. C++ is the fastest and most versatile language on the pla= net.=C2=A0 I don't see everyone jumping ship anytime soon for a complet= e rewrite language like D (sorry Andrei). We're stuck with C++, so lets= make it a better language.

Doing something like this would be huge. It would require a lot of anal= ysis to get right. My simple idea of =3Dvoid (inspired from D, thanks Andre= i) may not work in all cases and will need to be fleshed out further.

Please now, convince if you can why this is a bad idea. Why should we c= ontinue to inflict wasted hours of debugging sessions for these kinds of si= lly easy to write bugs on the future of C++? Can you think of any possible = reason uninitialized by default is good other than "maintaining legacy= code".



--

---
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>.
--089e011615fc6348cb04fc0a25ff-- .