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!
