Heh, I seem to be on a roll lately about this kind of stuff, oh well, here goes... I noticed a few places in the source where exit(1) is used to indicate a bad exit from the program. Unfortunately I don't have access to a copy of the latest (or any) ANSI/ISO C standards document and the outrageous fee that ANSI charges for one precludes any chance of my getting one (yeah, I could get a copy of Schildt's annotated C standard but I don't trust the guy enough to spend $40 on one of his books). Anyways, this is all to point out that I really can't quote from the standard and must rely on 2nd and 3rd hand interpretations of it when trying to code portably. Anyways, my understanding of the standard is that main can only return one of three values, those being 0 (to indicate success), EXIT_SUCCESS (which is #defined to 0 in stdlib.h), or EXIT_FAILURE (which is #defined to some non-zero value in stdlib.h). An implementation can make use of other return values but does not have to and any other return values do not necessarily indicate success or failure. Note that that since exit() is is implicitly called with the return value of main the same general rules apply to calling exit() as to what values can be returned from main(). Now after noticing a few instances where exit(1) is apparently used (in all likelihood incorrectly) to indicate failure I did the following from the shell... $grep -n 'exit(1)' *.c act.social.c:188: exit(1); act.social.c:208: exit(1); act.social.c:224: exit(1); ban.c:302: exit(1); boards.c:147: exit(1); comm.c:232: exit(1); comm.c:242: exit(1); comm.c:290: exit(1); comm.c:293: exit(1); comm.c:308: exit(1); comm.c:392: exit(1); comm.c:402: exit(1); comm.c:419: exit(1); comm.c:427: exit(1); comm.c:459: exit(1); comm.c:488: exit(1); comm.c:495: exit(1); comm.c:527: exit(1); comm.c:542: exit(1); comm.c:1905: exit(1); comm.c:1923: exit(1); comm.c:1974: exit(1); /* perhaps something more elegant should comm.c:2345: exit(1); comm.c:2382: exit(1); db.c:422: exit(1); db.c:428: exit(1); db.c:505: exit(1); /* Some day we hope to handle these things better... */ db.c:550: exit(1); db.c:562: exit(1); db.c:593: exit(1); db.c:640: exit(1); db.c:698: exit(1); db.c:707: exit(1); db.c:727: exit(1); db.c:767: exit(1); db.c:772: exit(1); db.c:782: exit(1); db.c:788: exit(1); db.c:809: exit(1); db.c:827: exit(1); db.c:848: exit(1); db.c:852: exit(1); db.c:871: exit(1); db.c:970: exit(1); db.c:977: exit(1); db.c:1000: exit(1); db.c:1006: exit(1); db.c:1015: exit(1); db.c:1021: exit(1); db.c:1135: exit(1); db.c:1141: exit(1); db.c:1181: exit(1); db.c:1191: exit(1); db.c:1208: exit(1); db.c:1247: exit(1); db.c:1263: exit(1); db.c:1267: exit(1); db.c:1275: exit(1); db.c:1279: exit(1); db.c:1288: exit(1); db.c:1292: exit(1); db.c:1319: exit(1); db.c:1332: exit(1); db.c:1337: exit(1); db.c:1344: exit(1); db.c:1357: exit(1); db.c:1380: exit(1); db.c:1388: exit(1); db.c:1400: exit(1); db.c:1407: exit(1); db.c:1436: exit(1); db.c:1452: exit(1); db.c:2209: exit(1); db.c:2227: exit(1); fight.c:123: exit(1); fight.c:143: exit(1); handler.c:373: exit(1); handler.c:861: exit(1); shop.c:987: exit(1); utils.c:546: * You still want to call abort() or exit(1) for $grep -n EXIT_FAILURE *.c $ Notice that there are an enormous number of exit(1)'s with absolutely no useage of the correct form exit(EXIT_FAILURE). Possible oversight, or ? Regards, Peter -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/03/01 PST