Re: symlink/readlink and trailing slash

[Eric Blake]

Jim Meyering <jim <at> meyering.net> writes:

> >       [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.

The jury's still out on this one.  On my first run on an actual Linux machine, 
I discovered that readlink("link",buf,0) returned -1 instead of the POSIX-
specified 0.  And looking at the Linux man-page, it claims that it returns 
EINVAL for non-positive length (although I have not had time to verify if that 
was indeed the errno that I got).

Then there was Solaris 8, where symlink("","link") worked (and behaved like 
symlink(".","link") in terms of referencing through the symlink), such that 
readlink actually should return 0 on that system.  Linux rejects a content-free 
symlink (POSIX neither requires nor forbids that behavior).

I also noticed that since readlink used to return int but now returns ssize_t, 
there are some platforms (like cygwin 1.5.x) where using readlink as a function 
pointer gave a compiler warning about incompatible pointers, so I'm trying to 
clean that up, too.

-- 
Eric Blake