From -1369694450247935234 X-Google-Thread: f78e5,e2cfdf64f67c7793 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!newsgate.cistron.nl!news.cambrium.nl!news.cambrium.nl!news.netcologne.de!nhp.netcologne.de!news.clara.net!wagner.news.clara.net!194.159.246.34.MISMATCH!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: invalid@bigfoot.com (Bob Hairgrove) Newsgroups: comp.std.c++ Subject: Re: Eliminating uninitialised variables Date: Tue, 21 Sep 2004 17:37:15 GMT Organization: Cablecom Newsserver Lines: 98 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.demon.co.uk 1095788239 25416 158.152.254.254 (21 Sep 2004 17:37:19 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Tue, 21 Sep 2004 17:37:19 +0000 (UTC) X-Received-SPF: none (mailbox6.ucsd.edu: domain of invalid@bigfoot.com does not designate permitted sender hosts) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Spam-Checker-Version: SpamAssassin 2.64-mulga_r1 (2004-01-11) on mulga.cs.mu.OZ.AU X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64-mulga_r1 X-Path: comp-std-cpp-robomod!not-for-mail X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id i8LHbF2K020745; Wed, 22 Sep 2004 03:37:15 +1000 (EST) X-NNTP-Posting-Date: Tue, 21 Sep 2004 09:32:30 +0000 (UTC) X-Spam-Level: X-Delivered-To: std-c++@ucar.edu X-Spamscanner: mailbox6.ucsd.edu (v1.5 Aug 25 2004 09:28:35, 0.1/5.0 3.0.0-rc1) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Newsreader: Forte Free Agent 1.93/32.576 English (American) X-Newsgroups: comp.std.c++ X-MailScanner: PASSED (v1.2.8 43385 i8L9WVNS051983 mailbox6.ucsd.edu) Xref: g2news1.google.com comp.std.c++:2804 On Mon, 20 Sep 2004 23:24:35 CST, brangdon@cix.co.uk (Dave Harris) wrote: >In a comp.lang.c++.moderated thread about const correctness, the issue of >uninitialised variables came up. Accessing an uninitialised variable is a >source of undefined behaviour which requires constant programmer vigilance >to avoid. A mistake often leads to real bugs or crashes, which can be >irreproducible and so hard to track down. > >Can we do something constructive towards fixing this? Has it been tried; >are there known problems? Here are my initial thoughts. > >We can't require the compiler to reject (at compile time) accesses of >uninitialised variables without breaking existing code, so I think we >would instead have to require all variables to be initialised - >zero-initialised as if they were statics. Since accessing an uninitialised >variable is currently undefined behaviour, a conforming program could not >tell the difference. I can think of two possible objections: > >(1) A good compiler could use the undefined behaviour to detect accidents >at run-time, by secretly initialising to a trapping value. > >(2) Efficiency. > >The efficiency issue we can probably handle by providing a way to request >uninitialised variables explicitly. Eg reusing the keyword "void": > int x; // x is 0. > int y = void; // y is uninitialised. > >The important cases are arrays: > int array[1000] = void; > >especially when they are instance variables: > > struct S { > int array[1000]; > S() : array(void) {} > }; > >I'm not wedded to this particular syntax. The point is that leaving a >variable uninitialised is an optimisation that should be requested >manually. (In many cases, of course, the compiler can optimise out >redundant zero-initialisation without help.) > >A compiler could trade speed for safety by using trapping values for void, >but I doubt that deals with the issue raised in (1). The concern is with >cases where: > >(a) A programmer adds a new variable to a class. >(b) The programmer forgets to update a constructor, so it gets >zero-initialised. >(c) Zero-initialisation is not sufficient to satisfy the class invariant. > >Personally I don't consider this serious enough to block the proposal. I >don't even know of an implementation which does use trapping values to >catch cases like this at run time. Comments? > >Other points... with Java the zero-initialisation of a derived class >happens before the base class's constructor is run. I think this should be >permitted in C++, but I'm not sure it should be required. On the other >hand, it probably does no harm and I expect most implementations will want >to zap the whole memory block in one operation anyway. > >Zeros are cheaper when bought in bulk, especially if they can be produced >in idle time, and especially if the O/S makes them. So it would be nice if >we could make zero-initialisation the responsibility of the memory manager >rather than the class's constructor. However, I don't see how to achieve >this without breaking backwards compatibility. Probably it should be a >quality of implementation issue anyway. It would be fairly easy to require either malloc or operator new to zero-initialize all storage it allocates. The question is, do we want to do this all the time? >This would be a difference in behaviour between C++ and C. I don't think >it will cause problems, but perhaps someone with more experience will >comment. > >What else am I missing? This is surely the kind of thing which future >revisions of the C++ standard should be considering. I don't think it is worth doing. Zero-initialization doesn't really make sense for object type members, anyway. I think it's just part of the job of programming to ensure that member variables are properly initialized, and with properly designed classes, it's not such a big chore. I's one of those things that make C++ different from, say, Visual Basic . -- Bob Hairgrove NoSpamPlease@Home.com --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]