This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Path processing bug


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Christopher Faylor on 8/21/2005 9:17 PM:
> I really don't care about POSIX in this case because I don't care about
> slavish adherence to POSIX standards at the expense of decreasing cygwin
> performance, adding a lot of complexity, or removing functionality.

POSIX is purposefully written to allow implementation extensions, it's
just that portable programs cannot rely on those extensions existing on
all platforms.  I also see your point that slowing cygwin down to comply
with POSIX is sometimes at odds with making cygwin useful (I don't intend
for this mail to be a flame war).

> 
> For example, I don't want to make Cygwin 1% slower so that a corner case
> problem like foo/../bar will work correctly

How often does the substring /../ actually appear in path name resolution?
 I don't think it is all that often, and the penalty for getting that
corner case POSIXly correct need not affect the common case when /../ is
not part of the path name.  Besides, the code in path.cc is already doing
something with /../ or you wouldn't be shortening '/dir/../' to '/'.

Another point to consider - in shells, POSIX requires `cd ..' uses logical
paths, so the shell itself must already flatten /../ components before
ever calling chdir(2), so that you can logically cd out of a symlink the
same way you got into it.  It is only `cd -P ..' that uses physical paths,
and which would actually pass ".." to chdir(2).

> and I don't want to remove
> functionality from 'tar' because the 't' option to fopen() isn't
> mentioned by POSIX.

This is different - recognizing fopen(name, "rt") is an extension to
POSIX; nothing in POSIX says you can't have that extension.  It's just
that nothing in POSIX defines what it means, so a portable program can't
use it and expect to work on other platforms.  There's nothing wrong with
tar or any other cygwin program using non-portable code if it makes the
job easier; it is just harder to port such non-portable code back upstream.

> 
> And, although I use SUSv3 as a reference, when I'm looking for
> compatibility, I really only care about how things work on linux.  If
> there is a conflict between POSIX and linux, then linux wins, unless
> there is a really compelling case otherwise.  Luckily, usually linux
> and SUSv3 agree.

I have personally encountered several places where Linux and SUSv3
disagree; for example Linux allows hard links to symlinks when POSIX
currently forbids it (although the Austin group had quite a heated
discussion as to whether that should be made legal in the next revision of
POSIX), and Linux has a different return type to strerror_r than POSIX,
making that function pretty much unusable in portable programs (again, the
Austin group is tracking a list of these types of incompatibilities,
http://www.opengroup.org/platform/single_unix_specification/doc.tpl?gdid=6995,
in hopes of resolving them in a future revision of POSIX).  I agree that
following Linux instead of SUSv3/POSIX is usually a safe course for
cygwin.  But Linux DOES correctly dereference '/../' in path names passed
to the kernel.

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDCcfW84KuGfSFAYARAufXAKDCn0L+5E5o+W0BkbFLj79lzx5BQwCfdz/Z
/yE+2bTxbryFhr1wkwSUgNM=
=BJ0W
-----END PGP SIGNATURE-----

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]