readlink() patch

Egor Duda
Sun Sep 3 23:09:00 GMT 2000


Monday, 04 September, 2000 Chris Faylor wrote:

CF> This is from my linux man page:

>>READLINK(2)         Linux Programmer's Manual         READLINK(2)
>>       readlink - read value of a symbolic link
>>       #include <unistd.h>
>>       int readlink(const char *path, char *buf, size_t bufsiz);
>>       readlink  places the contents of the symbolic link path in
>>       the buffer buf, which has size bufsiz.  readlink does  not
>>       append  a NUL character to buf.  It will truncate the con-
>>       tents (to a length of  bufsiz  characters),  in  case  the
>>       buffer is too small to hold all of the contents.
>>       The  call  returns  the  count of characters placed in the
>>       buffer if it succeeds, or a -1 if an error occurs, placing
>>       the error code in errno.
>>       ENOTDIR A component of the path prefix is not a directory.
>>       EINVAL  bufsiz is not positive.
>>               A pathname, or a component of a pathname, was  too
>>               long.

CF> To me, this means that removing ENAMETOOLONG is the wrong way to go.

susv2 says about ENANETOOLONG:

The readlink() function will fail if:

        Search permission is denied for a component of the path prefix of path.
        The path argument names a file that is not a symbolic link. 
        An I/O error occurred while reading from the file system. 
        A component of path does not name an existing file or path is an
        empty string. 
        Too many symbolic links were encountered in resolving path. 

        The length of path exceeds {PATH_MAX}, or a pathname component is
        longer than {NAME_MAX}. 
        A component of the path prefix is not a directory. 

    The readlink() function may fail if: 

        Read permission is denied for the directory. 

        Pathname resolution of a symbolic link produced an intermediate
        result whose length exceeds {PATH_MAX}.

Note that there's no notions about buffer size here.

Egor.   ICQ 5165414 FidoNet 2:5020/496.19

More information about the Cygwin-patches mailing list