[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [address@hidden: Re: serious bug. Evolution and Microsoft mentality.
From: |
Jeroen Dekkers |
Subject: |
Re: [address@hidden: Re: serious bug. Evolution and Microsoft mentality.] |
Date: |
Fri, 11 Jan 2002 22:21:17 +0100 |
User-agent: |
Mutt/1.3.25i |
On Fri, Jan 11, 2002 at 03:20:20AM +0000, Adam Olsen wrote:
> The basic question is whether realpath() uses _POSIX_PATH_MAX as the
> limit, which is a useful behavior (atleast as far as realpath goes),
> or whether it uses no limit at all, which is as useless as gets().
>
> As for portability, I think the best is to use canonicalize_file_name
> when it's available, and fallback to realpath if it's not. Otherwise,
> although your program would compile, it'd be broken if you ever got a
> path that was too long (either by crashing or getting the file wrong).
> And don't say it won't happen. The hurd is *alot* more flexible than
> traditional systems, so it's more than possible somebody could dream
> up a use for it in the future.
I read the austin draft 7. The with realpath() generated pathname is
stored as a nul-terminated string, up to PATH_MAX bytes. If PATH_MAX
doesn't exist, there is just no limit. You never know how big the
returned string and realpath() would just cause a buffer
overflow. _POSIX_PATH_MAX has nothing to do with it, it just specifies
a minimum for PATH_MAX, a system may not define a lower value.
Jeroen Dekkers
--
Jabber supporter - http://www.jabber.org Jabber ID: jdekkers@jabber.org
Debian GNU supporter - http://www.debian.org http://www.gnu.org
IRC: jeroen@openprojects.net
pgpD9YzxZsSoW.pgp
Description: PGP signature