On Fri, Jan 11, 2002 at 10:21:17PM +0100, Jeroen Dekkers wrote: > 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.
Note that our current glibc implementation (stdlib/canonicalize.c) will hardcode a fixed max size of 1024 for the string returned by realpath if PATH_MAX and pathconf don't indicate a limit. Yes, if you define your own PATH_MAX in your application, and use 512 (or anything smaller than 1024), you have a potential buffer overflow for each realpath() invocation if your program runs on the Hurd. Obviously, realpath() behaviour on non-PATH_MAX systems is not specified. Looks like a bug in POSIX to me. On the GNU system, using canonicalize_file_name is the way to go. All other systems I know are safe because they define PATH_MAX. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd
