Subject: Re: lib/30943: realpath() behaviour changed with nonexistant relative path
To: None <lib-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Quentin Garnier <cube@cubidou.net>
List: netbsd-bugs
Date: 08/10/2005 14:11:01
The following reply was made to PR lib/30943; it has been noted by GNATS.

From: Quentin Garnier <cube@cubidou.net>
To: gnats-bugs@netbsd.org
Cc: enami@netbsd.org, markd@netbsd.org
Subject: Re: lib/30943: realpath() behaviour changed with nonexistant relative path
Date: Wed, 10 Aug 2005 16:10:02 +0200

 --U/5EjKfnYgGK6hcj
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Mon, Aug 08, 2005 at 10:32:00AM +0000, Mark Davies wrote:
 > >Number:         30943
 > >Category:       lib
 > >Synopsis:       realpath() behaviour changed with nonexistant relative p=
 ath
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       high
 > >Responsible:    lib-bug-people
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Mon Aug 08 10:32:00 +0000 2005
 > >Originator:     Mark Davies
 > >Release:        NetBSD 3.99.7
 > >Organization:
 > Victoria University of Wellington
 > >Environment:
 > System: NetBSD lap2.home.vuw.ac.nz 3.99.7 NetBSD 3.99.7 (MCS_GEN_LAPTOP) =
 #0:=20
 > Thu Aug 4 14:07:55 NZST 2005=20
 > mark@lap2.home.vuw.ac.nz:/mnt/SAVE/build.obj/mnt/src/src/sys/arch/i386/co=
 mpile/MCS_GEN_LAPTOP=20
 > i386
 > Architecture: i386
 > Machine: i386
 > >Description:
 > 	Changes made to realpath() in July have changed its behaviour when given=
  a
 > 	non-existant relative path (such as "applications-merged/"). Its current
 > 	behaviour not only differs from the previous NetBSD behaviour but also f=
 rom
 > 	that on Solaris and Linux and breaks its usage in KDE.
 > >How-To-Repeat:
 > 	Compile and run the following program:
 >=20
 > #include <sys/param.h>
 > #include <stdlib.h>
 > #include <stdio.h>
 >=20
 > main()
 > {
 >   char foo[MAXPATHLEN];
 >   char *bar;
 >=20
 >   bar =3D realpath("applications-merged/", foo);
 >   printf ("<%s><%s>\n", bar ? bar : "(null)", foo);
 > }
 >=20
 > 	On -current it produces:
 > </tmp/applications-merged></tmp/applications-merged>
 > 	On NetBSD pre 1 July it produces:
 > <(null)></tmp/applications-merged>
 > 	On Solaris 9:
 > <(null)><applications-merged/>
 > 	On Linux (fedora 3)
 > <(null)></tmp/applications-merged>
 
 Elad's change in revision 1.37 of lib/libc/gen/getcwd.c introduced that
 behaviour.  Looking at it, the part of that changes that produces that
 only continued the idea of allowing a last non-existing component.
 
 =46rom my test, Linux doesn't allow this, and that's exactly what Mark
 shows us here.
 
 What's the rationale for allowing a inexistant last component?  Looking
 at the diffs, that behaviour comes straight from Lite2 which introduced
 realpath(3).
 
 It should be noted that the specification says we have to return ENOENT
 in that case:
 
 [ENOENT]
     A component of file_name does not name an existing file or file_name
     points to an empty string.
 
 --=20
 Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
 "When I find the controls, I'll go where I like, I'll know where I want
 to be, but maybe for now I'll stay right here on a silent sea."
 KT Tunstall, Silent Sea, Eye to the Telescope, 2004.
 
 --U/5EjKfnYgGK6hcj
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.6 (NetBSD)
 
 iQEVAwUBQvoKutgoQloHrPnoAQJExggAr2PDzpeyE7vK0Zx5VUhhXTrvBct467Za
 Fi3at6Md2nD0Txi7rPodFBFq6W/f2Ap+cAynxFViNdYmH9C7BX64t+h7/sZ9n7km
 p8BsbikJBcVxGg2cUGO93f7uxQ3iiW2nAXOA6BnfrMnGCOnOy5Bg0MF+qNmJBfQy
 RCljVp+0KrnDJyiFUsMYWpx/cagQkeSe48ESYZ0Dg9K/lu9AdKM8ElU3gKLoB2Vr
 uqaEEDdQoRdvJdlYQafb7T0bwqx124bdxG/teaO+UgLIZNM4ihNMqpjtocHWgOFT
 fNnIgVKuLAwZ7/cSBL8jBWNT8d/SCKSdfYDDsf4Q4VrVVtPYJ/6IOg==
 =spmS
 -----END PGP SIGNATURE-----
 
 --U/5EjKfnYgGK6hcj--