Subject: Re: pkg/20978: mail/deliver is not compatible with recent NetBSD libc
To: None <,,>
From: Greg A. Woods <>
List: current-users
Date: 04/07/2003 13:29:08
[ On Monday, April 7, 2003 at 17:54:54 (+0100), David Laight wrote: ]
> Subject: Re: pkg/20978: mail/deliver is not compatible with recent NetBSD libc
> On Mon, Apr 07, 2003 at 10:54:57AM -0400, Todd Vierling wrote:
> > 
> > NetBSDheads:  Is there really a reason not to return a pointer into the
> > existing string?
>     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().

That's a (poor) excuse, not a reason.

Why make something less portable (real-world portable, that is) than it
already was?  Why make something unusable in threaded applications,
especially when it was usable before?

The excuse given by the person who made the change was:

revision 1.5
date: 2002/10/17 02:06:04;  author: thorpej;  state: Exp;  lines: +26 -14
Change basename(3) and dirname(3) to return a pointer to static
storage, rather than modifying their input arguments.  While not
reentrant, this is explcitly allowed by IEEE Std 1003.1-2001 (which
allows either behavior, stating that it is implementation-dependent).

The new semantics are considered less hostile/more useful by most programs
which use basename(3) and/or dirname(3) (several programs in the NetBSD
tree reimplement basename()/dirname() themselves to avoid modification
of the input argument).

This new implementation truncates results to PATH_MAX.  The Std does
not address this in the static storage case.  However since PATH_MAX
is the maximum pathname length in the Std, this should not be a problem
in practice.  Nontheless, it is noted in the BUGS section.

See the basename(3)/dirname(3) regression tests in src/regress/lib/libc.

Inspired by discussion with Niels Provos, related to PR 18647.

IMVNSHO it was the code in bin/systrace/intercept.c which was broken,
especially since the manual page has always warned of this behaviour,
just as the above quoted bit of POSIX 1003.1-2001 also warns of it too.

Breaking a whole lot of other code just to "fix" that one instance is
certainly not justifiable, especially when the original implementation
did not violate the standards either.

								Greg A. Woods

+1 416 218-0098;            <>;           <>
Planix, Inc. <>; VE3TCP; Secrets of the Weird <>