moran@yale-zoo-suned..arpa (William L. Moran Jr.) (12/22/87)
In article <1293@laidbak.UUCP> daveb@laidbak.UUCP (Dave Burton) writes: ... > >OK. They are equivalent. >K&R says so, K&P says so, H&S says so, etc., etc. > >Have return and exit() always been equivalent? > >If so, why is there an exit() function call, since > the semantics are the same? I hate to make a silly observation like this, but return and exit aren't the same (they don't have the same semantics) except perhaps when used in main. Unless I am mistaken, exit() will leave from anywhere, and return() returns to the calling function (in main this is like an exit(). Perhaps I have missed the point, but I'm sure someone will tell me if this is the case. William L. Moran Jr. moran@{yale.arpa, cs.yale.edu, yalecs.bitnet} ...{ihnp4!hsi,decvax}!yale!moran Charm is the great English blight. It does not exist outside these damp islands. It spots and kills anything it touches. It kills love; it kills art; I greatly fear, my dear Charles, it has killed you. Brideshead Revisited
alex@CS.UCLA.EDU (12/23/87)
In article <1293@laidbak.UUCP> daveb@laidbak.UUCP (Dave Burton) writes: >OK. [return and exit()] are equivalent. >K&R says so, K&P says so, H&S says so, etc., etc. > >Have return and exit() always been equivalent? > >If so, why is there an exit() function call, since > the semantics are the same? A *return from main* and exit() are equivalent. But you can use exit() to leave your program from any function within it. If nothing else, exit() is convenient for fatal-error handlers. Alex
rmtodd@uokmax.UUCP (Richard Michael Todd) (12/23/87)
In article <1293@laidbak.UUCP> daveb@laidbak.UUCP (Dave Burton) writes: >Have return and exit() always been equivalent? >If so, why is there an exit() function call, since > the semantics are the same? A return n from the function main() is equivalent to exit(n) on most (but not, alas, all) implementations. But, if in some other function you need to suddenly exit the program (say, on discovery of some catastrophic error condition), you need a way to exit the program then and there; that's what you need exit() for. -------------------------------------------------------------------------- Richard Todd USSnail:820 Annie Court,Norman OK 73069 UUCP: {allegra!cbosgd|ihnp4}!occrsh!uokmax!rmtodd
daveb@laidbak.UUCP (Dave Burton) (12/23/87)
In article <20664@yale-celray.yale.UUCP> moran@yale-zoo-suned.UUCP (William L. Moran Jr.) writes: >In article <1293@laidbak.UUCP> daveb@laidbak.UUCP (Dave Burton) writes: >>If so, why is there an exit() function call, since >> the semantics are the same? >I hate to make a silly observation like this, but return and exit >aren't the same (they don't have the same semantics) except perhaps >when used in main. Unless I am mistaken, exit() will leave from Red-faced, he sends a Cancel out. (Please Cancel - catch them quick!) You're not mistaken. The question was absurd! I promise I won't do it again. I hope. -- --------------------"Well, it looked good when I wrote it"--------------------- Verbal: Dave Burton Net: ...!ihnp4!laidbak!daveb V-MAIL: (312) 505-9100 x325 USSnail: 1901 N. Naper Blvd. #include <disclaimer.h> Naperville, IL 60540
swarbric@tramp.Colorado.EDU (SWARBRICK FRANCIS JOHN) (12/23/87)
They're saying that return is the same as exit() WHILE IN main()! What exit() actually does is drops out of the WHOLE PROGRAM, while return just drops out of the current function. Dropping out of main() is (usually) equivalant to dropping out of the whole program. Frank Swarbrick swarbric@tramp.Colorado.EDU ...!hao!boulder!tramp!swarbric
john@viper.Lynx.MN.Org (John Stanley) (12/26/87)
In article <10033@shemp.UCLA.EDU> alex@CS.UCLA.EDU (Alex Quilici) writes: > >A *return from main* and exit() are equivalent. In theory: maybe. In practice: not-on-a-bet....! This is a long standing illusion. For practical reasons, many implementors of the C language have had to make a concession to how people have been told (by K&R no less) to write a main() function. There are two ways for a call to main() to be written: 1) /* used in most of the crt0.c code that I've seen */ main(argc, argv); exit(0); 2) /* what Alex would expect */ exit(main(argv, argc)); The first version above will insure that a program that does not return anything from main has a zero exit code... This also means that any main that returns something will also have a zero exit code (not what Alex expects, but something that can be overcome by using an exit() call if the programmer desires to return something other than zero...). The second version insures that a value returned from main will be accepted as an exit code, but also insures a random return value for programs with a main that doesn't end with a return. I'm sure you'll all agree that a random return value isn't desireable? There are an abundance of existing programs that -do-NOT- return any value from main. They just terminate. There is no way of telling what the value handed back to the calling crt0() function will be. You may say these are poorly written, I'd tend to agree, but in this situation, poor style isn't really relevant...they exist and part of the objective for the ANS standard is to not break existing code... (Examples of this style are in K&R and must be considered part of the baseline definition of how many people have been writing main() functions for years.) What this all boils down to is this... If a programmer wants to return any value to the operating system and have the program work on a large number of existing implementations (that use version one -or- version two of the main() call I listed), he/she -must- use exit(). Any other method will not work on many existing systems... Assuming that returning a value from main will work is logical, but it just won't work... If the ANS standard does not deal with this problem, it should do so before being released. This dicotomy has existed for years and is exactly the kind of thing the committee needs to solve once and for all... >But you can use exit() to leave your program from any function within >it. If nothing else, exit() is convenient for fatal-error handlers. Regardless of which way the ANS standard is written, if you use exit to return a value out of your program, it will work. This makes exit more than just a convenience, it's a necessity for anyone who has to write code that needs to be portable. --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!meccts!viper!john
ok@quintus.UUCP (Richard A. O'Keefe) (12/27/87)
From K&R and Univ V7 I expected that just falling off the end of main() would be equivalent to exit(0). Then I used System V/386, and a lot of my makefiles broke. Now I try to end main() with exit(0); /*NOTREACHED*/ } The ANSI C committee would have a hard time making the portability of programs which rely on falling of the end of main() any worse; to ensure [that's the right spelling] that your programs will work in >UNIX< you had better stick to exit().
guy@gorodish.Sun.COM (Guy Harris) (01/05/88)
> 1) /* used in most of the crt0.c code that I've seen */ > main(argc, argv); > exit(0); You obviously haven't seen: 1) the 4.2BSD or 4.3BSD VAX "crt0" code; 2) the System V Release 2 VAX "crt0" code; 3) the SunOS "crt0" code prior to release 2.0; 4) the System V Release 3 WE32K "crt0" code; 5) etc. then. That behavior is actually quite common, at least in UNIX systems.... Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/06/88)
In article <454@viper.Lynx.MN.Org> john@viper.UUCP (John Stanley) writes: > This is a long standing illusion. For practical reasons, many >implementors of the C language have had to make a concession to how >people have been told (by K&R no less) to write a main() function. Excuse me, but I don't believe K&R discusses whether or not main() is even considered to return a value, much less what should happen to it. (Remember that K&R C did not distinguish between int-valued functions and void-valued functions; "void" was not even in the language.) >There are two ways for a call to main() to be written: > 1) /* used in most of the crt0.c code that I've seen */ > main(argc, argv); > exit(0); Not ANSI-conforming. > 2) /* what Alex would expect */ > exit(main(argv, argc)); This is what the UNIX crt0 (run-time startup module that calls main()) has done since I can remember, certainly for very many years. (Well, actually not too long ago it started passing also an envp argument to main, but that's not relevant to the discussion.) >I'm sure you'll all agree that a random return value isn't desireable? Yes, and we've just about stamped out the vestigial remnants of that in the UNIX system utilities. For many years, several utilities did in fact return garbage status to the execution environment (wait() status) because they were written in old K&R style rather than reporting proper status. >situation, poor style isn't really relevant...they exist and part >of the objective for the ANS standard is to not break existing code... Sorry, but using the main() return value as an implicit exit() parameter is also widespread existing practice, and many of us have relied on it for many years. Code that fails to indicate its termination status is simply broken in that regard, and for an implementation to take it upon itself to report such code as "always successful" is presumptuous. >(Examples of this style are in K&R and must be considered part of the >baseline definition of how many people have been writing main() >functions for years.) You could also say that about the UNIX C implementation(s), which even predate K&R. >If the ANS standard does not deal with this problem, it >should do so before being released. This dicotomy has existed for >years and is exactly the kind of thing the committee needs to solve >once and for all... Yes, it's been taken care of -- adopting the UNIX approach rather than the "invent a status for the sloppy SOB" approach. > Regardless of which way the ANS standard is written, if you use exit >to return a value out of your program, it will work. This is good advice for those who have to deal with portability to a wide variety of pre-ANSI C, non-UNIX environments, poor souls.