bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: symlink/readlink and trailing slash


From: Eric Blake
Subject: Re: symlink/readlink and trailing slash
Date: Wed, 23 Sep 2009 05:52:34 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

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

According to Jim Meyering on 9/22/2009 11:17 AM:
> Eric Blake wrote:
>> That Solaris 9 bug of ignoring trailing slash is pervasive.  I'm looking at
>> committing this series next, once I run it through tests on more machines.
> 
> These look like fine improvements.  Although I haven't reviewed them
> carefully, I suggest you go ahead and commit them whenever you're ready.

I've now tested on Linux, OpenBSD, Solaris 8-10, cygwin 1.5 and 1.7, and
mingw (on mingw, the tests skip, since there are no symlinks), and pushed
the series.  I was surprised to learn that modern BSD still has a return
type of int instead of POSIX-mandated ssize_t, which could potentially
cause problems on 64-bit machines (although why POSIX mandated ssize_t to
make readlink() look like read() is beyond me, since it is not likely that
a single symlink will ever contain 2 gigabytes of contents); so that is
also fixed in the series.  Now pushed to gnulib.

>> Should we make readlink have GNU
>> behavior on these platforms (returning truncated string instead of ERANGE
>> failure, and making areadlink/areadlink-with-size simpler as a result), or
>> should I go ahead and relax the testsuite to not expect success with a too-
>> small buffer?
> 
> Making it GNU-readlink-compatible sounds preferable.
> That's a little more work, but it would provide a tighter and
> more-generally-useful specification, and as you mention,
> a cleaner use in areadlink.c.

Chicken-and-egg problem - if readlink fails with ERANGE, you have to
supply a larger buffer before you know what contents to place in the
truncated buffer, just to throw that larger buffer away.  At this point,
I'd rather just stick with recommending areadlink (which also has the nice
property of guaranteed NUL-termination).  In other words, making readlink
return truncated contents instead of ERANGE would only make areadlink
slower, since areadlink already has to worry about supplying larger
buffers even if the result is successfully truncated instead of an ERANGE
failure.  I relaxed the test to allow AIX behavior instead (although I am
not in a position to test that the module works on that platform, so
hopefully we get some positive feedback).

- --
Don't work too hard, make some time for fun as well!

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

iEYEARECAAYFAkq6DAIACgkQ84KuGfSFAYAGDQCfWeWgK/Ocxw1zYezUq0e+E4os
0HUAoLYP71PV3tU1g1g52sDILvdKuOjl
=s+0K
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]