Re: symlink/readlink and trailing slash

[Jim Meyering]

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.

> Eric Blake (6):
>       [1/7] unistd: sort replacement declarations
> Similar to prior cleanups, makes adding symlink easier
>
>       [2/7] symlink: new module, for Solaris 9 bug
> symlink("a","b/") mistakenly creates "b" on Solaris 9.  Plus, this allows 
> calls
> to symlink to at least compile on mingw (although it doesn't magically work
> around the fact that the OS flat out doesn't have symlinks ;)
>
>       [3/7] symlink: use throughout gnulib
> symlink was mostly used in tests, which can be simplified by assuming symlink
> exists.  symlinkat continues to provide a direct ENOSYS failure on mingw,
> rather than wasting time going through save_cwd/fchdir/fail/restore_cwd.
>
>       [4/7] readlink: use correct return type
> readlink.c predates our unistd.in.h replacement header, which now guarantees
> ssize_t exists.  I don't know if this will have any impact on progreloc.c,
> since canonicalize-lgpl uses readlink (so we may need to add a declaration of
> readlink if !HAVE_READLINK in a couple of places).
>
>       [5/7] readlink: fix Solaris 9 bug
> readlink("link-to-dir/",buf,len) mistakenly read the contents of link-to-dir,
> rather than failing with EINVAL because the resolved directory dir/ is not a
> symlink.
>
>       [6/7] test-symlinkat: enhance test
> Solaris 9 lacks symlinkat and readlinkat (so no *at wrappers needed to work
> around these particular trailing slash bugs).  But enhancing the testsuite to
> make sure of this is always a good idea.

>       [7/7] readlink: document portability issue with symlink length
> Documentation improvement.  Hmm.  I guess this means test-readlink and test-
> symlinkat will now fail on AIX and HP-UX (I have access to neither, so I'm 
> just
> going off the comment in areadlink.c rather than a confirmed failure), because
> those platforms fail with ERANGE rather than truncate when the requested 
> length
> is too small for the symlink contents.  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.

Thanks!