Re: [Bug-gnulib] xreadlink.c patch

[Paul Eggert]

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


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

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

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