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
