From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Newsgroups: comp.lang.c
Subject: Re: Life, stderr, and everything (was Re: malloc() as a user...)
Date: 17 Oct 92 04:50:23 GMT
Organization: Computer Science, University of Melbourne, Australia

scs@adam.mit.edu (Steve Summit) writes:

>In several articles, Richard A. O'Keefe and Fergus James
>HENDERSON have been discussing the relative merits of calling or
>not calling perror after a malloc failure.  Fergus correctly
>claims that calling perror might produce meaningful information,
>and Richard correctly claims that it is not guaranteed to do so,
>and that it might therefore produce misleading information.
[...]
>There's a bit of game theory involved here, as represented in the
>following table:
>
>	+----------------+-------------------+----------------+
>	| chance that:   | if my code        | if my code     |
>	|                | interprets errno: | ignores errno: |
>	+----------------+-------------------+----------------+
>	| user sees      |                   |                |
>	| useful         |        99%        |        0%      |
>	| information    |                   |                |
>	+----------------+-------------------+----------------+
>	| user sees      |                   |                |
>	| misleading     |         1%        |        0%      |
>	| information    |                   |                |
>	+----------------+-------------------+----------------+
>	| user sees      |                   |                |
>	| no information |         0%        |      100%      |
>	+----------------+-------------------+----------------+
>
>Since the last column guarantees disgruntled users, I much prefer
>to muck about with the first one [3].  This is, however, very
>much a judgement call.  It's possible to be so worried about
>that 1% misleading factor (or to be so insistent upon certainty,
>for better or worse) that your decision swings to the last
>column.  There is also evidently a third possibility: the last
>time this subject was discussed, I got mail from someone who
>believed strongly that errno should be neither ignored nor
>interpreted via perror/strerror but rather printf'ed %d; this
>person was most concerned about the (nonzero, to be sure)
>probability that the perror text can be misleading for a
>particular choice of an errno value for a particular failure
>mode of a particular system call.

There is also a fourth possibility, which could be called hedging your bets:
you can include strerror(errno) in your error message, but absolve yourself
of responsibility for it's accuracy. This gives error messages like the
following:

    a.out: can't open file 'foo' for reading; the system reports the
    error message "Permission denied", but beware that on some systems
    these error messages may be uninformative, ambiguous, misleading or wrong.

This method of course has its own disadvantages...
	
>In spite of my obvious bias, I am not trying to argue one way or
>the other.  There is no one right answer here (i.e. Richard and
>Fergus are never going to convince each other); one has to decide
>based on a program's expected life history which approach is
>preferable.

Ye of little faith! :-)
I think that it is quite *possible* that we may be able to agree on some
compromise like conditional compilation, or run-time configuration based
on command-line switch/environment variable/configuration file.
OK, Maybe I'm an optimist :-)

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Xref: sparky comp.lang.c:14901 comp.lang.c++:14920 comp.os.msdos.apps:5143 comp.os.msdos.programmer:9866