On Mon, Apr 07, 2003 at 10:54:57AM -0400, Todd Vierling wrote:
> [Re-sent with proper Cc:.]

But still missing gnats-bugs@gnats.netbsd.org

> On Tue, 1 Apr 2003 jbernard@mines.edu wrote:
> 
> : 	The problem is that it uses the basename function to construct file
> : 	names [in lock.c (dotlock_name) and subs.c (unique)], and its usage
> : 	of basename assumes that the function returns a pointer that
> : 	references a location within the source string (which deliver then
> : 	uses to modify the string).  However NetBSD's libc/gen/basename.c
> : 	was changed on Oct. 17, 2002 (rev. 1.5 of basename.c) to always
> : 	return a pointer to static storage containing the base name, so
> : 	deliver fails to construct usable file names.
> 
> This is a severe problem.  I've seen other code which depends on basename
> returning an in-situ pointer, and the change to libc (without versioning the
> call because of the ABI change) is alarming.

Such code is non-portable (aka broken).

> NetBSDheads:  Is there really a reason not to return a pointer into the
> existing string?

http://www.opengroup.org/onlinepubs/009604499/functions/basename.html

    The basename() function may modify the string pointed to by path, and
    may return a pointer to static storage that may then be overwritten by a
    subsequent call to basename().

(NB basename is marked as an XSI extension to ISO C)

	David

-- 
David Laight: david@l8s.co.uk