karl@sugar.hackercorp.com (Karl Lehenbauer) (04/28/89)
Several years have elapsed, which should have been long enough to make all the programs distributed with Unix follow the perror() conventions that the manuals tell us our programs are to follow. Oh well. -- -- uunet!sugar!karl | "Nobody hipped me to that, dude." -- Pee Wee -- Usenet BBS (713) 438-5018
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/29/89)
In article <3759@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes: >Several years have elapsed, which should have been long enough to make all >the programs distributed with Unix follow the perror() conventions that >the manuals tell us our programs are to follow. (1) "what" uses fopen() to open the file. perror() is inappropriate except when a system call reports failure. fopen() is not a system call. (2) SCCS was developed long ago and hasn't been modernized.
friedl@vsi.COM (Stephen J. Friedl) (04/29/89)
In article <3759@sugar.hackercorp.com>, karl@sugar.hackercorp.com (Karl Lehenbauer) writes: > Several years have elapsed, which should have been long enough to make all > the programs distributed with Unix follow the perror() conventions that > the manuals tell us our programs are to follow. The perror() function has been SVID level 2 since 1985, which means that it is no longer guaranteed to be supported after 1988. I believe it will be in the next SVID (Issue 3), but it may go away after that. This matters, of course, only if you value the SVID. Steve -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / friedl@vsi.com / {attmail, uunet, etc}!vsi!friedl As long as Bush is in office, you'll never see Nancy Reagan in *my* .sig.
bill@twwells.uucp (T. William Wells) (04/30/89)
In article <10156@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: : In article <3759@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes: : >Several years have elapsed, which should have been long enough to make all : >the programs distributed with Unix follow the perror() conventions that : >the manuals tell us our programs are to follow. : : (1) "what" uses fopen() to open the file. perror() is inappropriate : except when a system call reports failure. fopen() is not a system call. According to the manual pages for Microport V/386 3.0e, fopen returns an error status in errno and perror is defined to work for system calls and library functions. I don't have the manual pages for other systems handy, but I seem to recall similar wording for BSD and SunOS. --- Bill { uunet | novavax } !twwells!bill
bink@aplcen.apl.jhu.edu (Ubben Greg) (04/30/89)
In article <10156@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > (1) "what" uses fopen() to open the file. perror() is inappropriate > except when a system call reports failure. fopen() is not a system call. > ... I regularly use perror() to report the failure of an fopen(). It works on all the systems I've used because, of course, the fopen() doesn't make any other system calls after the open(). Is this really a bad thing to do? confirm: -- Greg Ubben bink@aplcen.apl.jhu.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/01/89)
In article <1153@aplcen.apl.jhu.edu> bink@aplcen.apl.jhu.edu (Greg Ubben) writes: >I regularly use perror() to report the failure of an fopen(). It works on >all the systems I've used because, of course, the fopen() doesn't make any >other system calls after the open(). Is this really a bad thing to do? Yes, because there can be causes for fopen() failing that are not related to system calls the fopen() implementation may make. For example, suppose there is a fixed array of FILE structures and they've all been allocated. No system call will occur, and any perror() you do will give completely mileading information about the problem. By now everyone must have seen at least one report "not a typewriter" due to a call to perror() under inappropriate circumstances. If you have a fairly high degree of certainty that nothing could have gone wrong that didn't involve a system call failure, then feel free to use perror(), but you're always taking a risk when using perror() after a non system-call library function.
john@frog.UUCP (John Woods) (05/02/89)
In article <1153@aplcen.apl.jhu.edu>, bink@aplcen.apl.jhu.edu (Ubben Greg) writes: > In article <10156@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > > (1) "what" uses fopen() to open the file. perror() is inappropriate > > except when a system call reports failure. fopen() is not a system call. > I regularly use perror() to report the failure of an fopen(). It works on > all the systems I've used because, of course, the fopen() doesn't make any > other system calls after the open(). Is this really a bad thing to do? "Of course" you actually know no such thing. However, the SVID guarantees that if fopen() or freopen() fails, then errno shall contain a valid error code. (note, as usual, the refusal to state what errno contains if fopen() succeeds. It will contain a dragon.) "system call" is not well enough defined to be the determinant of whether errno is usable or not (after all, why IS open() a system call, and why IS NOT fopen() a system call?). What you ought to rely on is what a common manual documents. (Gee, one of the rare times when Doug Gwyn isn't right. He must have done this deliberately to reassure all of us that he's human :-). -- John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu
decot@hpisod2.HP.COM (Dave Decot) (05/02/89)
> > (1) "what" uses fopen() to open the file. perror() is inappropriate > > except when a system call reports failure. fopen() is not a system call. > > I regularly use perror() to report the failure of an fopen(). It works on > all the systems I've used because, of course, the fopen() doesn't make any > other system calls after the open(). Is this really a bad thing to do? It's not bad on an X/Open system. X/Open recognized the widespread use of perror() after library routines that can experience underlying system errors, and gave this practice its blessing. Therefore, systems that claim compliance to Issue III of the X/Open Portability Guide will set errno for these functions as documented. Note that IEEE Standard 1003.1 (POSIX) also appears to require this behavior for systems implementing the Standard C Language Binding. Dave Decot Past Chair X/Open System Interface Working Group
guy@auspex.auspex.com (Guy Harris) (05/02/89)
>The perror() function has been SVID level 2 since 1985, which >means that it is no longer guaranteed to be supported after 1988. >I believe it will be in the next SVID (Issue 3), but it may go >away after that. And then again, it may not. "perror" is in the pANS for C, so even if AT&T rips it out of the SVID, vendors will probably have to provide it anyway in their C implementations.
guy@auspex.auspex.com (Guy Harris) (05/02/89)
>According to the manual pages for Microport V/386 3.0e, fopen returns >an error status in errno and perror is defined to work for system >calls and library functions. > >I don't have the manual pages for other systems handy, but I seem to >recall similar wording for BSD and SunOS. No, I checked the 4.3-tahoe and SunOS 4.0 "fopen" man pages; they mention "errno" nowhere.
guy@auspex.auspex.com (Guy Harris) (05/02/89)
>Yes, because there can be causes for fopen() failing that are not related >to system calls the fopen() implementation may make. For example, suppose >there is a fixed array of FILE structures and they've all been allocated. >No system call will occur, and any perror() you do will give completely >mileading information about the problem. In which case I'd prefer to use "open" to open the file, and "fdopen" to turn it into a standard I/O stream; given the choice between using a strictly conforming application not using anything outside the ANS which just says "Sorry, I can't open your file", and one that uses POSIX functions but tells me *why* it can't be opened, there'd better be a big cost difference, or the latter'd better not be available on all the platforms I'm interested in, or the former had better be better than the latter for other reasons, 'cause I'm going to count the better error disagnostic as a serious point in favor of the latter application.... >By now everyone must have seen at least one report "not a typewriter" >due to a call to perror() under inappropriate circumstances. I'd be willing put up with a few of those, if it's the price I have to pay for better error diagnostics. (I'd really have preferred it if "errno" had been officially guaranteed to be set properly after failure of things such as "fopen" (assuming that, in this hypothetical world, some other error-reporting mechanism weren't used), but....)
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/04/89)
In article <1350@frog.UUCP> john@frog.UUCP (John Woods) writes: >In article <1153@aplcen.apl.jhu.edu>, bink@aplcen.apl.jhu.edu (Ubben Greg) writes: >>[...] >(Gee, one of the rare times when Doug Gwyn isn't right. He must have done >this deliberately to reassure all of us that he's human :-). That was Ubben Greg, not me. It's well known that I'm not human. SVID and POSIX requirements that fopen() always set errno appropriately upon failure are fairly recent innovations, and not all UNIX implementations religiously do that. It's certainly true that it's not clear what really is or should be a "system call" versus a "library function", but at one time you could apply the rule: If it's in the UPM Section 2 it's a system call; if it's in Section 3 it's a library function. Thus my UNIX System V emulation for 4.nBSD systems takes considerable pains to set errno on failure for all its emulations of System V system calls, but doesn't do anything special when non-math library functions fail. That's consistent with traditional practice, although not apparently with POSIX.