Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: ericblake AT comcast DOT net (Eric Blake)
To: cygwin AT cygwin DOT com
Subject: Re: Problem with sh/bash and snapshot cygwin1-20050825.dll
Date: Fri, 26 Aug 2005 15:20:42 +0000
Message-Id: <082620051520.16535.430F334A000C799B0000409722007613940A050E040D0C079D0A@comcast.net>

> >Because POSIX states that buf is indeterminate on error, and
> >because Corrina's patch caused a regression (ie. 1.5.18 was
> >setting buf[0] to 0 on error).  QofI states that we might as
> >well make the indeterminate buffer useful, in case a user
> >forgets to check the return value being NULL.
> 
> linux leaves the buffer alone, as far as I can tell.

Well, we should be consistent.  In 1.5.18, realpath ALWAYS
set buffer[0] to 0 on error.  In 20050825, it sets buffer[0]
to 0 on all errors except EINVAL.  Either we never touch
buffer on error (a change from 1.5.18, but justifiable if Linux
does so), or we always do the same thing (either my patch
to cygwin-patches, or change it to also leave buffer alone
on ENOENT, etc.).  There's also the matter of the comment
in path.cc about the idea of setting buffer to the component
that failed resolution, although that is not done in cygwin
(ie. realpath("/tmp/nonesuch/x/", buf) returns NULL with
ENOENT, but leaves buf as "/tmp/nonesuch"), also a valid
QofI approach but much harder to implement.

--
Eric Blake


--
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/