File: [cvs.NetBSD.org] / src / lib / libc / gen / basename.c (download)
Revision 1.5, Thu Oct 17 02:06:04 2002 UTC (21 years, 6 months ago) by thorpej
Branch: MAIN
CVS Tags: yamt-pf42-baseX, yamt-pf42-base, wrstuden-fixsa-newbase, wrstuden-fixsa-base-1, wrstuden-fixsa-base, wrstuden-fixsa, netbsd-4-base, netbsd-4-0-RELEASE, netbsd-4-0-RC5, netbsd-4-0-RC4, netbsd-4-0-RC3, netbsd-4-0-RC2, netbsd-4-0-RC1, netbsd-4-0-1-RELEASE, netbsd-4-0, netbsd-4, netbsd-3-base, netbsd-3-1-RELEASE, netbsd-3-1-RC4, netbsd-3-1-RC3, netbsd-3-1-RC2, netbsd-3-1-RC1, netbsd-3-1-1-RELEASE, netbsd-3-1, netbsd-3-0-RELEASE, netbsd-3-0-RC6, netbsd-3-0-RC5, netbsd-3-0-RC4, netbsd-3-0-RC3, netbsd-3-0-RC2, netbsd-3-0-RC1, netbsd-3-0-3-RELEASE, netbsd-3-0-2-RELEASE, netbsd-3-0-1-RELEASE, netbsd-3-0, netbsd-3, netbsd-2-base, netbsd-2-1-RELEASE, netbsd-2-1-RC6, netbsd-2-1-RC5, netbsd-2-1-RC4, netbsd-2-1-RC3, netbsd-2-1-RC2, netbsd-2-1-RC1, netbsd-2-1, netbsd-2-0-base, netbsd-2-0-RELEASE, netbsd-2-0-RC5, netbsd-2-0-RC4, netbsd-2-0-RC3, netbsd-2-0-RC2, netbsd-2-0-RC1, netbsd-2-0-3-RELEASE, netbsd-2-0-2-RELEASE, netbsd-2-0-1-RELEASE, netbsd-2-0, netbsd-2, nathanw_sa_before_merge, nathanw_sa_base, matt-mips64-base, matt-mips64, matt-armv6-prevmlocking, matt-armv6-nbase, matt-armv6-base, matt-armv6, keiichi-mipv6-base, keiichi-mipv6, hpcarm-cleanup-base, hpcarm-cleanup, fvdl_fs64_base, cube-autoconf-base, cube-autoconf, abandoned-netbsd-4-base, abandoned-netbsd-4 Branch point for: yamt-pf42
Changes since 1.4: +26 -14
lines
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.
|