When the standard was originally being written, there were a few places
where
more than one error condition was permitted for the same problem, and
there were
other adaptations to the existing practice of the time.
Systems that deviate from the standard that came to exist after the
standard was
published (including, assuredly, "my own") have no excuse not to conform
to the
standard as written, if they choose to claim conformance. If we don't
hold a
bright line on this, the standard will have no purpose: if every time
someone
"invents" or "goofs" and doesn't follow the standard, and we allow that,
then
the standard will cease to provide what it exists for: application
portability.
"Standard is better than better." -- Portia Isaacson. (sp?)
Donn
-----Original Message-----
From: yyyyyyyyyyyyyyy@xxxxxx [mailto:yyyyyyyyyyyyyyy@xxxxxx]
Sent: Wednesday, April 10, 2002 10:46 AM
To: yyyyyy@xxxxxxxxxxxxx; yyyyyyyyyyyyyyy@xxxxxxxxxxxxx;
yyy@xxxxxxxxxxxxxxxxxxx
Subject: Re: Defect in XSH unlink
Andrew,
The current EPERM covers two cases:
1. The named file is a directory and the calling process does not
have
appropriate privileges, and
2. The named file is a directory and the implementation prohibits
using unlink() on directories.
If I were inventing a new operating system from scratch today, I
would
agree that case 2 should be EISDIR. But I believe it is too late to
rewrite this much history and EPERM should continue to be used for
both
of these errors on any UNIX/POSIX system implementation. I see no
reason why applications that have been written to POSIX (1988
through
the present) should be subjected to this arbitrary change in
behavior.
Things depend on your definition of POSIX system.
There are lots of minor differences between almost any Unix-like system
and the POSIX standard. Certainly 4.3BSD that you quote does not fully
conform to POSIX.
These days we also have Linux as an important example of a Unix-like
system. I don't know whether Andrew's question was inspired by it, but
Linux returns EPERM in case 1, and EISDIR in case 2.
So "it is too late to rewrite history" does not really apply. History
was rewritten already. Every portable application will today have to
reckon with the possibility of an EISDIR return.
Andries
|