of course!

[Larry McVoy]

In article <1989Nov22.224209.28911 at athena.mit.edu> jik at athena.mit.edu (Jonathan I. Kamens) writes:
>In article <1051 at root44.co.uk> gwc at 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 at sun.com