Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!decwrl!ucbvax!YALE.ARPA!LEICHTER-JERRY From: LEICHTER-JERRY@YALE.ARPA.UUCP Newsgroups: mod.computers.vax Subject: Re: main() and entry points in C Message-ID: <8607180838.AA19654@ucbvax.Berkeley.EDU> Date: Fri, 18-Jul-86 04:38:27 EDT Article-I.D.: ucbvax.8607180838.AA19654 Posted: Fri Jul 18 04:38:27 1986 Date-Received: Fri, 18-Jul-86 18:37:54 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 92 Approved: info-vax@sri-kl.arpa I received a private copy of Joe Yao's message, with no indication that it had also been forwarded to info-vax. The following is the response I sent him, slightly amended. For info-vax readers, there is some repetition here; my apologies. Unless someone brings up startling new facts, this is my last message on this subject. I promise. :-) -- Jerry If some implementation of C uses _start instead of start as an entry point, they are asking for trouble. I have never seen a C-accessible symbol as an entry. The entry point, start, used to be almost always 0; but it isn't ever 0, now, in the latest releases of AT&T System V Unix. Try the Celerity 4.2bsd port - their entry point is BOTH start (no "_") and something like _crt0_start. The latter IS accessible from C - and has a value of 0. I'm told that this is not uncommon, although I can't name any other examples. I DO know that the Pyramid port - at least the 4.2bsd universe version, I didn't try the System V one - uses start (no "_") only. On many versions of Unix, it is documented that properly written multiple-language modules can be compiled together by appropriately calling the compiler: cc myc.c myftn.o ... or f77 myftn.f myc.o ... or even f77 myftn.f myc.c ... "Many versions" of Unix? I thought we were talking about one portable OS here! :-) You claim this is a documented undocumented feature? It isn't even true. Specifically, never_called() { printf("Hi. Joe is wrong.\n"); } main() { printf("Hello world.\n"); } will never call me a liar. Even if you are talking about straight link-loaded objects (with no header to call _main()), several common loaders allow one to specify entry points other than 0. These include, but are not! limited to, the AT&T System V ld (again); the CULC Fortran IV Plus linker; and the DEC VMS linker. Mr. Shein forwarded only the last of a series of messages on this topic. He did this because he was interested in flames, not facts. (Mr. Shein sent me a note saying he would forward my message, "without editorial comment," to "the C experts" on info-c/net.lang.c. His interpretation of "without editorial comment" allowed him to include a "summary line" of "Combating nonsense". My, my. Mr. Yao's response is the first one, after about 2 weeks, that actually talks about the issues - there were a couple of others pointing out related bugs in various microprocessor C implementations. There's been nothing further from Mr. Shein.) The whole discussion started with a question from a VMS C user as to why, if he didn't provide a main() routine, his VMS C code started at the first function seen by the VMS linker. (Well, that wasn't QUITE his question - others asked that, the original questions shows up below.) As my original response pointed out, the Unix linker does exactly the same thing, if you invoke it "straight"; it's only because of the way cc chooses to invoke the linker that stuff works out. If you do things the "supported" way in VAX C, you get exactly the same results as if you do them the "supported" way on Unix C. But, in fact, even if you go beyond the "supported" approaches, the results on VMS are a pretty close approximation to what you get on Unix. The C header, which cc puts at the head of the compiled objects, contains the entry point -- which is not at location 0 under all versions of Unix! This header moves the argc, argv, and envp to a location that main() will understand when called as a function; then calls main() as a function; then calls exit() as a function whose argument is main()'s return value; and if this doesn't exit, typically tries to perform an exit system call itself, and then (in desperation) a halt. Again, all of these points were brought up in messages that Mr. Shein chose to omit. Interestingly enough, the original message complained that, with previous versions of VMS C, a program without a main(), called at its first function, received its command line arguments - but that in recent versions this didn't work "unlike Unix". In fact, this does NOT work in Unix! I should say it TYPICALLY does all this. If it ain't documented (and especially if it's not in the standard), it ain't guaranteed, so don't bet the lunch money, Mildred. K&R defines the semantics of C programs. They provide a definition for how C programs start up (in main()). They also provide a definition for how functions get called. Nowhere is there a definition of the semantics of a complete program WITHOUT a main() function - implementations are on their own here. The VMS implementation tries to emulate what most Unix implementations seem to do. It comes pretty close. Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} jsdy@hadron.COM (not yet domainised) -- Jerry -------