Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!philmtl!ray
From: ray@philmtl.philips.ca (Raymond Dunn)
Newsgroups: comp.lang.c
Subject: Re: entry at other than main (was want to know)
Message-ID: <657@philmtl.philips.ca>
Date: 21 Aug 89 20:19:13 GMT
References: <8487@bsu-cs.bsu.edu> <2980@solo9.cs.vu.nl> <182@sunquest.UUCP> <2563@trantor.harris-atd.com> <19164@mimsy.UUCP>
Reply-To: ray@philmtl.philips.ca (Raymond Dunn)
Organization: Philips Electronics Ltd. -  St. Laurent  P.Q., Canada
Lines: 37

In article <19164@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
 >In many articles many people write this, that, and the other argument
 >for or against `main()' as the program entry point.
 >
 >Personally, I do not see this as much of an issue.

Neither do I, however:

 >Anyway, this gives us some background with which to consider the
 >options available.  We have four standard approaches available:
 >	a) program begins at procedure or function declared with
 >	   some special syntax;
 >	b) program begins at top;
 >	c) program begins at reserved name (`main');
 >	d) program begins at any function (Lisp, APL, etc).

A fifth approach in use that Chris seems to have missed:

	e) program begins at the external symbol specified at link time.

Thus part of the "ideal" approach that Chris suggests is already prior art:

 >  We could allow programs to declare each entry point with a
 >`program' or `entry' statement, and thus share subroutines and get the
 >effect of switching on argv[0] on Unix machines, as ex/vi/view/edit/e
 >and compress/uncompress do.  To do this we must have the compiler and
 >the linker cooperate...

There is no doubt that this is a cheap elegant "best" solution.

The fact that 'C' doesn't have it is only marginally a problem at worst.

-- 
Ray Dunn.                    | UUCP: ..!uunet!philmtl!ray
Philips Electronics Ltd.     | TEL : (514) 744-8200  Ext: 2347
600 Dr Frederik Philips Blvd | FAX : (514) 744-6455
St Laurent. Quebec.  H4M 2S9 | TLX : 05-824090