X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: David Kastrup <dak AT gnu DOT org>
Subject:  Re: Problem with stat
Date:  Wed, 27 Jun 2007 10:26:15 +0200
Lines: 49
Message-ID:  <86wsxpiz14.fsf@lola.quinscape.zz>
References:  <46808EA8 DOT 2030202 AT pacific DOT net DOT sg> <4680DD73 DOT 8090300 AT sh DOT cvut DOT cz> <4680E3A0 DOT 3020508 AT pacific DOT net DOT sg> <4680FE40 DOT 7010102 AT byu DOT net> <46810D24 DOT 9000303 AT pacific DOT net DOT sg> <46810FAA DOT 5050508 AT byu DOT net> <86zm2mdfox DOT fsf AT lola DOT quinscape DOT zz> <468112F2 DOT 10802 AT byu DOT net> <86vedade9q DOT fsf AT lola DOT quinscape DOT zz> <loom DOT 20070626T160440-648 AT post DOT gmane DOT org> <86ps3irapu DOT fsf AT lola DOT quinscape DOT zz> <f5re1l$f40$1 AT sea DOT gmane DOT org> <loom DOT 20070626T183345-273 AT post DOT gmane DOT org>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.51 (gnu/linux)
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Eric Blake <ebb9 AT byu DOT net> writes:

> Matthew Woehlke <mw_triad <at> users.sourceforge.net> writes:
>
>> >> "If the named file is a symbolic link, the stat() function shall
>> >> continue pathname resolution using the contents of the symbolic
>> >> link, and shall return information pertaining to the resulting file
>> >> if the file exists."
>> > 
>> > This says nothing about what is returned if the file does not exist.
>> 
>> RETURN VALUE
>>      Upon successful completion, 0 shall be returned. Otherwise, -1 shall
>>      be returned and errno set to indicate the error.
>
> Matthew is right.

I have no doubt that he is right about what programs do.  I am just
pointing out that it involved an advanced degree in lawyering and
sophistry to extract this kind of information from the standard.
Which makes the standard badly worded, at the very least.

> And if that isn't enough to convince you, you should also read POSIX
> XBD 4.11, which talks all about pathname resolution.
> http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html

Yes, that is more clear.  But it does not help one standard that a
different standard is more careful in its wordings.

> Since stat() is not one of the special functions that operates on
> symlinks, it MUST resolve whatever the link points to, and if the
> link is broken, then it must behave the same way it does for any
> other resolution failure, ie. in this case, fail with ENOENT.  In
> short, it is IMPOSSIBLE for stat() to give you a struct stat that
> passes S_IFLNK on a compliant platform.  Give up your argument now.
> There are enough of us on this list that know POSIX and SUSv3 that
> you will not win.

Whatever.  I fail to see that the first wording of the standard is so
unambiguous that I would bet my life on S_ISLNK never returning true
on a dead link accessed with stat, when the implementor was of the
opinion of following the standard's wordings.

In short: I was not talking about what behavior to _implement_ but
rather what behavior to _expect_.  And given the fuzzy wording, I find
the intent to be reasonably well hidden here.

-- 
David Kastrup


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/