Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!snafu!lm
From: lm@snafu.Sun.COM (Larry McVoy)
Newsgroups: comp.unix.wizards
Subject: Re: of course!
Message-ID: <128791@sun.Eng.Sun.COM>
Date: 5 Dec 89 09:07:00 GMT
References: <152@norsat.UUCP> <2586@unisoft.UUCP> <15769@bloom-beacon.MIT.EDU> <17264@rpp386.cactus.org> <4526@ski.cs.vu.nl> <17303@rpp386.cactus.org> <1051@root44.co.uk> <1989Nov22.224209.28911@athena.mit.edu>
Sender: news@sun.Eng.Sun.COM
Reply-To: lm@sun.UUCP (Larry McVoy)
Organization: Sun Microsystems, Mountain View
Lines: 59

In article <1989Nov22.224209.28911@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes:
>In article <1051@root44.co.uk> gwc@root.co.uk (Geoff Clare) writes:
>=>>	isadir(char *path)
>=>>	{
>=>>		char dir[PATH_MAX];
>=>>
>=>>		strcpy(dir, path);
>=>>		strcat(dir, "/.");
>=>>
>=>>		return access(dir, 0);
>=>>	}
>=The fact that the strcat() may write past the end of dir[] is more of
>=a problem.
>
>  Yes, this is definitely a problem.  There should be a check on the
>length of path before strcat'ing onto the end of it.
>
>=            Another is that PATH_MAX might not be defined (it should
>=always be obtained via pathconf() in portable applications).
>
>  Not convinced this is a major problem.  I've yet to run into a Unix
>programming environment that doesn't somewhere in a header file give
>you some indication of the maximum path length, although that may be
>just my limit Unix experience talking.  I also don't know about
>non-Unix C libraries....

The standard programming practice that I've seen is

isadir(char *path)
{
	char	dir[_POSIX_PATH_MAX];

	/* etc */
}

I don't think this is a good thing to do.  The reason is that the 
_POSIX_* values are intended to be the minimum allowable values.
That means, you can alwasy count on *at least* _POSIX_PATH_MAX space
in a pathname, but it may be more.  The better model, albeit slower, is

isadir(char *path)
{
	char	*dir;

	dir = malloc(pathconf(path, _PC_PATH_MAX));

	/* etc */
}

The whole point is that this value could change.  Consider a diskless
machine with NFS, RFS, or God knows what mounted up.  One remote filesystem
might be a System V (14 char names); another might be DOS.  So you really
need to ask.  As far as I know there is no constant that will work all
the time.  I don't like it either, but what is a better solution?  I can't
see anyway to provide a fixed answer in the face of remote file systems.

	 What I say is my opinion.  I am not paid to speak for Sun.

Larry McVoy, Sun Microsystems                          ...!sun!lm or lm@sun.com