bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnulib] xreadlink.c patch


From: Mark D. Baushke
Subject: Re: [Bug-gnulib] xreadlink.c patch
Date: Tue, 02 Nov 2004 22:10:03 -0800

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Eggert <address@hidden> writes:

> "Mark D. Baushke" <address@hidden> writes:
> 
> > The existing readlink.c is a stub for systems that do not have one. I
> > would expect there to need to be a rpl_readlink version if it were going
> > to adapt to the behavior of dealing with incompatible behaviors.
> 
> Yes, that's what I was thinking of.  The basic idea is that
> application code need only "#include <readlink.h>" and that is enough
> to get a working readlink.  Or perhaps you can fix things so that we
> don't even need "#include <readlink.h>".

Hmmm... The basic problem is that 'real' readlink () function is not
giving us any intermediate filling of the buffer... just an ERANGE error
return.

It seems like repl_readlink() is going to need to do something like:

 1) Try to find out how must space is needed and get the whole thing right
   a) do an lstat() on the symbolic link,
   b) use the size of the link (plus one) to malloc/alloca a buffer
   c) call the 'real' readlink() function
   d) make sure there were still no errors
   e) copy as much of the readlink() full buffer results into the user
      provided buffer as is possible
   f) free the buffer if it was malloc()d
   g) return the results.
 2) Basically go thru the same basic xreadlink() algorithm again and account
    for the possiblity of errno == ERANGE and not be discouraged and continue
    to bump the buffer size by two.

It would seem more optimal to put the fix into xmalloc() because it is
already adjusting the size of the buffer it is creating... otherwise,
why is xreadlink() not just doing the stat in the first place itself?

> >> it assumes SSIZE_MAX < SIZE_MAX, but POSIX does not require this....
> >
> > If POSIX does not require it, does that imply that you may be truncating
> > the result when you do the link_length = r  assignment?
> 
> Yes, but that's harmless here.
> 
> > That is, will SSIZE_MAX > SIZE_MAX ever be true?
> 
> Yes, that's the idea: POSIX does not rule out that possibility.  Dunno
> if there are any platforms like that now, but there are some
> advantages to having SSIZE_MAX >= SIZE_MAX so it's possible someone
> will do it one of these days.  If it's easy to support such platforms,
> we might as well do it now (while we're thinking about it).

I suspect if it happens it will break at least a few applications that
are assuming there would be little difference between the two, but it
is good to know that it is possible...

> > Should xreadlink.c do
> > #include "xsize.h"
> 
> xsize.h is somewhat controversial, due to its treatment of overflow.
> I'd rather avoid it if it's easy (which is the case here).

Hmmm... are those guidelines written anywhere in the documentation yet?

> > I am curious to know if it makes more sense to use xrealloc()
> 
> In general I prefer using free/malloc to realloc in cases where the
> buffer contents need not be preserved.  This is to some extent a style
> issue, though one can easily construct scenarios where free/malloc
> will run faster because buffer contents don't need to be copied.

Okay, I can understand that point of view as well.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFBiHY73x41pRYZE/gRAjYCAJ0dD+s41Zbg7FN7bbk2adw9Nu5gUgCdEpjq
j21VJi3Jec9G4df/Nc9PhCs=
=EYjq
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]