From: "Douglas A. Gwyn" <gwyn@arl.army.mil>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] the declaration of main()
Date: Thu, 26 Apr 2001 15:55:51 +0000 [thread overview]
Message-ID: <3AE83DB0.5F698867@arl.army.mil> (raw)
In-Reply-To: <20010424081352.B166E19A61@mail.cse.psu.edu>
forsyth@caldo.demon.co.uk wrote:
> i realised later that i hadn't pointed out that regardless whether
> int main was a good choice for the C standard, it had further
> disadvantages in plan 9.
It needn't have. Standard C of necessity provides a "lowest
common denominator" fit to existing target environments;
there are many systems (including Unix and VMS) that report
termination status as more than just success/failure, but
they do it in different ways. Except for Plan 9's native
(non-APE) and some standalone environments, main() *does*
in fact return an int, even if many programmers believed
otherwise. (On many platforms it is accidentally possible
to misdeclare main() and still get an executable that appears
to work.) The C standard had to codify existing practice
(where there was already consensus), not try to change it.
> plan 9 does not use an integer for exit status: it uses a string.
> if it's considered desirable to return status from main, it would
> need to be char*, which is still different from the C standard.
No, there was an unhappy design decision. Since there was
already a standard interface definition for the external
function name "main", Plan 9's startup entry point for user
code should have been given a different name, perhaps "start"
or "mains". Then the Plan 9 library would provide a function:
/* mains -- no need for APE since we conform to C99 */
char *mains(int argc, char **argv) {
exits(main(argc, argv) ? "FAILED" : "");
}
> ... void main was the better choice.
No, that choice pretty much forced the existence of an APE.
If the standard extern interfaces had been honored, Plan 9
C could support both the native Plan 9 way of doing things
*and* Standard C, without requiring any flags etc.
As a general design principle, whenever you find that two
similar but different approaches have been created, there
has been a lack of vision. We see this in the two kinds
of "character" support in Standard C, for another example.
next prev parent reply other threads:[~2001-04-26 15:55 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-24 8:10 forsyth
2001-04-26 15:55 ` Douglas A. Gwyn [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-04-30 12:05 rob pike
2001-04-30 10:44 forsyth
2001-04-28 18:44 forsyth
2001-04-30 9:24 ` Douglas A. Gwyn
2001-04-28 17:57 forsyth
2001-04-28 22:28 ` Dan Cross
2001-04-30 9:25 ` Douglas A. Gwyn
2001-04-27 6:57 nemo
2001-04-26 20:58 forsyth
2001-04-27 9:13 ` Douglas A. Gwyn
2001-04-27 14:48 ` Boyd Roberts
2001-04-27 16:22 ` Douglas A. Gwyn
2001-04-27 18:24 ` William K. Josephson
2001-04-30 9:23 ` Douglas A. Gwyn
2001-04-27 19:38 ` Boyd Roberts
2001-04-28 15:54 ` Greg Hudson
2001-04-28 16:39 ` Dan Cross
2001-04-28 17:06 ` Boyd Roberts
2001-04-30 9:25 ` Douglas A. Gwyn
2001-04-26 19:42 Russ Cox
2001-04-26 20:32 ` Dan Cross
2001-04-26 22:03 ` Boyd Roberts
2001-04-27 9:13 ` Douglas A. Gwyn
2001-04-26 18:23 forsyth
2001-04-26 19:17 ` Mike Haertel
2001-04-26 23:50 ` Boyd Roberts
2001-04-27 14:41 ` Douglas A. Gwyn
2001-04-27 15:40 ` Boyd Roberts
2001-04-27 9:12 ` Douglas A. Gwyn
2001-04-24 10:32 rog
2001-04-24 18:03 ` Steve Kilbane
2001-04-24 0:59 okamoto
2001-04-24 3:08 ` Boyd Roberts
2001-04-23 19:33 dmr
2001-04-23 11:09 forsyth
2001-04-23 11:31 ` Boyd Roberts
2001-04-24 9:02 ` Douglas A. Gwyn
2001-04-24 12:09 ` Boyd Roberts
2001-04-26 16:05 ` Douglas A. Gwyn
2001-04-26 18:12 ` Boyd Roberts
2001-04-26 23:55 ` Boyd Roberts
2001-04-24 17:43 ` Greg Hudson
2001-04-26 15:55 ` Douglas A. Gwyn
2001-04-12 6:28 okamoto
2001-04-23 8:44 ` Douglas A. Gwyn
2001-04-23 8:48 ` Boyd Roberts
2001-04-12 6:22 YAMANASHI Takeshi
2001-04-12 6:25 ` andrey mirtchovski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3AE83DB0.5F698867@arl.army.mil \
--to=gwyn@arl.army.mil \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).