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: 15 Oct 92 17:09:03 GMT
Organization: Computer Science, University of Melbourne, Australia

ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:

>In article <9228916.10105@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU
>(Fergus James HENDERSON) continues an argument he and I seem to be
>having about the merits of using perror() after a failed call to
>malloc().

Can we call it a "friendly discussion"? :-)

[...]
>The point is that C programmers on UNIX systems (and others)
>have *no* *way* *to* *know* whether malloc() sets errno or not
>other than reading the source code of their particular runtime library.

If we don't know, then we can wait until malloc actually does return NULL,
and then check errno. If it didn't set errno, this is perhaps disappointing,
but it doesn't cause any major problems.

[...]
>For the record, the "other" errno value is EAGAIN, which is not
>what you might call informative.  It certainly wouldn't tell Joe Luser
>anything useful.  In fact, just to prove my point, here's what would
>be produced if I called perror after a failed call to malloc() in the
>System V.3 variant:
>
>	No more processes
>
>Do you *really* want to claim that I "_should_ call perror to pass"
>THAT (mis)"information on to the user"?

If malloc() sets errno to a value that is misleading, then you should
complain to your vendor. If the message corresponding to a particular
error number is misleading, then you should complain to your vendor.

On *my* system, the error message for EAGAIN is the more informative
	Resource temporarily unavailable
which you probably *would* want to pass on to Joe Luser.

>If there is only one error value, it is not useful to call perror.
[...]
>If there are several possible error values, it _still_ may not be useful
>to call perror.  UNIX errno values are "overloaded"; one number may be
>used to mean several different things depending on which system call
>reports it.  perror() doesn't know which system call reported the error,
>so for overloaded error numbers you *often* get inappropriate text.

If your system overloads error numbers in such a way as to cause
the error messages to be inappropriate, then complain to your vendor.

My manual page for perror() says:

     Perror produces a message on the standard error output, describing	the
     last error	encountered during a call to a system or library function.

If this message is not accurate, then that is a problem with perror(),
and it is the vendor's responsibility to fix it.

>It is not documented that malloc() sets errno at all.
>It is not documented that malloc() sets errno *meaningfully*.
[...]
>But please, people, I am not
>making it up, I am not exaggerating, when I say "you *CANNOT* trust errno
>EXCEPT when the documentation EXPLICITLY says you can", and when I advise
>you _not_ to rely on perror() for error messages sent to users.

This is rather depressing advice.
I just checked the documentation for fopen() on three different Unix systems,
and none of them mentioned anything about setting errno.
Does this mean that I can't use perror() when fopen() fails?
I sure as hell would like to be able to give the user an informative error
message in this case. (I have got a lot of programs (eg. gcc) that do
call perror() if fopen() fails - should I throw them away? :-)

Seriously, you may be right that some or many versions of Unix have
implemented error numbers and perror() rather poorly. This should
not however be taken as a good reason to stop using perror(); instead
we should demand decent implementations.

>My heart is pure:  I love UNIX and hate VMS just as I should.
>But in comparison with VMS status codes, UNIX errno values are _shocking_.

Well, my heart is pure also, but you have got me interested now:
could you please explain VMS status codes and why they are better than
Unix?

-- 
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!
Newsgroups: comp.lang.c