Date:	Wed, 14 Jun 2000 17:51:48 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Laurynas Biveinis <lauras AT softhome DOT net>
cc:	DJGPP Workers <djgpp-workers AT delorie DOT com>
Subject:	Re: Another one symlink patch
In-Reply-To:	<39478703.8ABA35E2@softhome.net>
Message-ID:	<Pine.SUN.3.91.1000614173902.995J-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, 14 Jun 2000, Laurynas Biveinis wrote:

> >      @item 17
> > 
> >     +ELOOP -- Too many levels of symbolic links.  Usually it means
> >     +encountered link loop (link1 -> link2; link2 -> link1).
> >     +
> >     +@item 18
> >     +
> >      EMFILE -- Too many open files in system (no more handles available).
> >      This usually means that the number specified by the @samp{FILES=}
> >      directive in @file{CONFIG.SYS} is too small.
> > 
> > This is wrong: those numbers in "@item 17" etc. are not ordinal
> > numbers, they are numerical values of the errno variable.  So ELOOP
> > should go under "@item 39" and you should leave the existing numbers
> > intact.
> 
> As I understand texinfo, @item specifies just a label in a table layout
> and the real EWHATEVER value does not matter there, does it?

No.  This is what @item in a @table produces:

  `18'
        EMFILE -- Too many open files in system (no more handles available).

So it shows both the numerical value and the text.

> > About `lstat': since `_is_executable' always resolves links, doesn't
> > it mean that the execute bit returned by `lstat' would be incorrect,
> > because it is taken from the target of a link?
> 
> I was 110% sure that I've included missing S_ISLNK *this time*.
> Guess if it is really so. But the real code sets all bits correctly, it
> looks like this:
> 
> if (readlink(......
> {
>    statbuf->st_mode |= S_ISLNK;
>    ...
> }
> else
> {
>     ... _is_executable and so on.
> }

I don't see this code inside `lstat' in your patches.  In fact, I don't 
see a call to `readlink' inside `lstat' at all (and I didn't expect to).

> Note that I'm already asking for FILENAME_MAX filename length. 
> I think I will do something like
> 
> char fn_buf[FILENAME_MAX + 1];
> ...
> do
> {
>    bytes_copied = readlink(real_path, fn_buf, FILENAME_MAX + 1);
>    if (bytes_copied == FILENAME_MAX + 1)
>    {
>       errno = ENAMETOOLONG;
>       return -1; 
>    }
> ...

I agree, but this probably should be mentioned in the docs as another way 
of checking `readlink's results.

- Raw text -