cvs commit: src/usr.sbin/kldxref kldxref.c

[Yar Tikhiy]

On Mon, Aug 07, 2006 at 01:59:30PM +1000, Bruce Evans wrote:
> On Sun, 6 Aug 2006, Dag-Erling [iso-8859-1] SmЬrgrav wrote:
> 
> >Marcel Moolenaar <marcel at FreeBSD.org> writes:
> >>  Log:
> >>  Fix (static) buffer overflow bug. The dest buffer is of size MAXPATHLEN,
> >>  so dest[MAXPATHLEN] falls outside the buffer.  This bug corrupted
> >>  arenas[0] defined in libc's malloc.c on PowerPC when kldxref is shared,
> >>  which triggered a delayed SIGSERV.
> >
> >MAXPATHLEN should be spelled PATH_MAX.
> 
> Actually, MAXPATHLEN is better since it is honestly unportable.  It works
> on all [Free]BSD systems, while PATH_MAX only works on POSIX systems that
> define it.  The correct spelling of PATH_MAX is {PATH_MAX} or:
> 
> #if defined(PATH_MAX) && defined(OPTIMIZE_FOR_COMPILE_TIME_CONST_PATH_MAX)
> 	char buf[PATH_MAX];
> 	...
> #else
> 	long path_max;
> 
> 	path_max = pathconf(pathname_of_interest, _PC_PATH_MAX);
> 	if (path_max == -1)
> 		handle_error();
> 	assert(path_max > 0 && path_max <= SIZE_MAX)
> 	buf = malloc((size_t)path_max);
> 	if (buf == NULL)
> 		handle_allocation_failure();
> 	...
> #endif
> 
> The correct spelling is too hard to use for simple unportable utilities
> like kldxref.

Just looked what SUSv3 says:

	It should be noted, however, that many of the listed limits
	are not invariant, and at runtime, the value of the limit
	may differ from those given in this header, for the following
	reasons:

	The limit is pathname-dependent.

	The limit differs between the compile and runtime machines.

	For these reasons, an application may use the fpathconf(),
	pathconf(), and sysconf() functions to determine the actual
	value of a limit at runtime.

Therefore using PATH_MAX alone doesn't buy us true portability
within POSIX.  Sigh...  It seems indeed better to use the good old
non-portable MAXPATHLEN rather than pretend portability falsely.

-- 
Yar