Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!decvax!ittatc!dcdwest!sdcsvax!ucbvax!YALE.ARPA!LEICHTER-JERRY From: LEICHTER-JERRY@YALE.ARPA Newsgroups: mod.computers.vax Subject: Re: main() and entry points in C Message-ID: <8606261219.AA02599@ucbvax.Berkeley.EDU> Date: Thu, 26-Jun-86 08:48:56 EDT Article-I.D.: ucbvax.8606261219.AA02599 Posted: Thu Jun 26 08:48:56 1986 Date-Received: Fri, 27-Jun-86 23:47:58 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 107 Approved: info-vax@sri-kl.arpa To: John Owens In-Reply-To: John Owens , Mon, 23 Jun 86 09:34:42 edt In general, I agree with what you say. A couple of small comments: C does *not* guarantee that address 0 doesn't contain anything, but that's another discussion. C DOES guarantee that the integer constant 0, cast to any pointer type, will never be equal to a pointer to any actual object of that type. In principle, the cast could change the bit pattern; it almost never does - certainly it does not on a VAX. Thus, _start == NULL. Most users will never see this, but an implementer of _start() would. (Minor point, but the fact is there IS an inconsistency - nothing keeps you from doing an extern void _start() and looking at the resulting pointer.) -- Well, getting there. I tried -- "ld foo.o /lib/libc.a". No errors! Running a.out produces "Hello -- world", followed by an access violation. Adding an explict exit(0) -- fixes that. This is certainly not supported. You were lucky. It's dependent on the implementation of the exec(2) system call whether or not you'll get your command line arguments this way. Actually, I've since been informed that, while argc is passed correctly, argv is screwy and envp isn't there at all. -- [...] but are you -- still going to bet that the first routine WON'T end up as the entry point? I won't bet on anything if the loader isn't invoked properly.... That gets to the crux of things: The "proper" way to invoke the loader is undocumented - you must use cc. How then do you deal with a program written in multiple languages? Basically, you ask a wizard.... I find it rather amusing that Unix, which (quite properly) argues for separate modules with separate functions, and clean interfaces between them, glues the loader and the C compiler together in a very ad hoc, undocumented way! (Side comment: You at least understand what Unix is doing here. I had a couple of other correspondents on this issue who had no real idea what was going on, and ended up effectively claiming that the loader really is part of the compiler. If that's the case, (a) it's going to be very hard to deal with multiple compilers, ever; (b) it becomes hard to justify why the loader doesn't do more to help the compiler/user out - e.g., check for type clashes in external function calls. This would have been trivial to do if the implementers had wanted to, with minimal overhead, and much faster than lint. Yes, it would have required additional facilities in C - argument definitions as in ANSI C - but then the language, compiler, and loader were developed by the same people at the same time. As for those other correspondents, their lack of knowledge didn't slow them down a bit in defending their incorrect religeous state- ments....) -- At worst, I was claiming that a lot of non-portable C code got written -- under Unix (since K&R certainly contains nothing to indicate that -- there can be an entry point other than main()). And if you don't -- believe THAT, then you haven't looked at much Unix code. That code you've been looking at is going to have a hard time being ported to most UNIX systems then, much less any other system with a C compiler. I've been porting, adapting, and randomly mangling C code for UNIX from a variety of sources for years, and haven't run into a single program that doesn't have an entry point of main(). Would you refer me to such a program that I might have access to, like something from USENET, a USENIX tape, or a System V or BSD distribution? If you read more closely what I said, you'll see that I didn't claim to have any examples of this kind of thing...I just claimed that, somewhere out there, they were likely to exist. I know the people who did the VAX C com- piler and run-time support, and they've tried really hard to be compatible with Unix. Unfortunately, that can be very hard to do, since Unix programs make use of a lot of undocumented "features". For example: There is abso- lutely nothing in any definition of C that says that in: f(a,b) int a,b; { int *x; x = &a + sizeof(int); ... } x will point to b. In a field-test version of VAX C V2.0, this was NOT true. (The VMS procedure-call spec says that the argument list is owned by the CALLING procedure, which may place it in read-only memory, re-use it, etc.; the CALLED procedure may only read it. In that version of C, if you ever took the address of a formal argument, the value passed was copied to a temporary cell on entry, and the address you got was of the temporary. As far as documented C semantics are concerned, this is a completely correct implementation - but it prevents you from screwing with the caller's argument list.) Anyway, cries of pain came from all over: Despite the existence of varargs - which WAS provided with that release, BTW - it turns out that there are LOTS of C programs that assume you can scan through an argument list this way. So the final version of V2 put things back as they were, requiring a waiver of conformance with this aspect of the procedure-call spec. (As it happens, VAX C (currently) always builds argument lists on the stack and then discards them, so you can screw around to your heart's content - but try it with a FORTRAN caller, and things get really weird....) Anyway, given that Unix programmers have historically grasped at ANYTHING they can find the least justification for in the documentation - or no justifica- tion at all - "compatibility" has to mean "put in EVERYTHING you can, even if you can't think of anyone who's using it. Someone will come along who wants it, some day...." Since the "entry point is the first routine" IS, in fact, documented - even if only for wizards! - supporting it couldn't hurt.... John Owens @ General Electric Company -- Jerry -------