9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
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.


  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).