On Mon, Apr 29, 2002 at 03:58:39PM -0700, Paul Eggert wrote:
> > Date: Tue, 30 Apr 2002 00:27:28 +0200
> > From: Jeroen Dekkers <yyyyyy@xxxxxxxxxx>
> >
> > I think the only possible fix is to define a new function, probably
> > returning a malloc()'d buffer.
>
> That is what `canonicalize_file_name' does in the GNU C library.
Yes, as it's the GNU system which doesn't have a limit on the size of
a path. I wonder why nobody reported this problem yet.
> Another possible fix is to have `realpath' malloc a buffer if its
> second argument is null. This would be a compatible extension to
> POSIX behavior.
>
> Even if it's out of scope for the TC to change the standard here,
> surely it's within scope to mention the problem in the rationale and
> to mention the glibc behavior as one possible extension.
Now I remind that getcwd() has the same problem, but in the GNU C
library it allocates the buffer is the pointer is NULL. Reading the
standard, it says that the behavior is unspecified if the pointer to
the buffer is NULL and the rationale says that some implementation
malloc() the buffer then. Can we do the same in the TC for realpath()?
That would fix the problem.
Jeroen Dekkers
--
Jabber supporter - http://www.jabber.org Jabber ID: yyyyyyyy@xxxxxxxxxx
Debian GNU supporter - http://www.debian.org http://www.gnu.org
IRC: yyyyyy@xxxxxxxxxxxx
pgp00009.pgp
Description: PGP signature
|