From 6574089322079483428 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,314ebdf2ff957e27 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-04-16 12:27:45 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: allan_w@my-dejanews.com (Allan W) Newsgroups: comp.std.c++ Subject: Re: Why int main()? Date: Wed, 16 Apr 2003 19:27:43 +0000 (UTC) Organization: http://groups.google.com/ Lines: 47 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <7f2735a5.0304161119.2d516e7d@posting.google.com> References: <3E9821CE.8AC8B8C6@web.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: mail2news.demon.co.uk 1050521263 27585 10.0.0.1 (16 Apr 2003 19:27:43 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Wed, 16 Apr 2003 19:27:43 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.12) id 195sZK-0007Am-00 for mail2news@news.news.demon.net; Wed, 16 Apr 2003 19:27:42 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id FAA25510; Thu, 17 Apr 2003 05:27:38 +1000 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ucar.edu X-Newsgroups: comp.std.c++ X-NNTP-Posting-Date: 16 Apr 2003 19:19:12 GMT X-Spamscanner: mailbox5.ucsd.edu (v1.2 Mar 17 2003 15:04:36, -0.4/5.0 2.43) X-MailScanner: PASSED (v1.2.7 2180 h3GJJD5R048043 mailbox5.ucsd.edu) X-Spam-Status: No, hits=-8.4 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Xref: archiver1.google.com comp.std.c++:18782 kanze@gabi-soft.de (James Kanze) wrote [re main() returning int] > - Why int? That's what Unix and MS-DOS used, but it certainly isn't > universal. The logical solution would have been an implementation > defined type, main_t with only the return of the macros EXIT_SUCCESS > and EXIT_FAILURE guaranteed by the standard. That would have broken > a lot of existing programs, however. Would it? Suppose we insist that either main_t is a typedef for int, or else it is convertible from int. Most programs would need only one trivial change in order to be compatible; furthermore, on existing platforms, the code would continue to function properly until this change was made. > - Why not allow void? Either define falling off the end of a void > main as equivalent to return EXIT_SUCCESS from a non-void main, or > say that any return value is undefined (which is what actually > happens in most implementations today). Or say that returning from > a void main is illegal (undefined behavior) -- generally, when > people write void main, it is because they don't return, either > because the program consists of an endless loop, or because they > always call exit. That hasn't been my experience. Most of the uses of "void main" that I've seen have been in textbooks! (Probably because I attack the practice whenever I see it.) Saying that "void main" indicates that the program never intends to exit is quite logical, but it doesn't match existing practice very well. I've been a strong proponent of ignoring void main, even when the local platform supports it -- but my impression is that a LOT of people routinely use it, without even realizing it's wrong. Which makes me think that maybe we should support it after all. The C++ standard is supposed to document existing practice, yes? Perhaps we should recognize any of these signatures: int main(int, char**); int main(); void main(); --- [ 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 ]