From owner-freebsd-current@freebsd.org Mon Nov 16 17:00:45 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 525BA46B2F5 for ; Mon, 16 Nov 2020 17:00:45 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CZb1T1smVz3r8M; Mon, 16 Nov 2020 17:00:45 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-WLAN.fritz.box (p50806a51.dip0.t-ipconnect.de [80.128.106.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id D92104530; Mon, 16 Nov 2020 17:00:44 +0000 (UTC) (envelope-from se@freebsd.org) To: FreeBSD CURRENT From: Stefan Esser Subject: [REVIEW] new function getlocalbase() - D27236 and D27237 Message-ID: Date: Mon, 16 Nov 2020 18:00:41 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NHAtD3kqYM3MFjd9Z7UrDTsfKhtZNKieQ" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 17:00:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NHAtD3kqYM3MFjd9Z7UrDTsfKhtZNKieQ Content-Type: multipart/mixed; boundary="AvaatoqjQlBdMedbF5n0D2EyTfRB8VrWt"; protected-headers="v1" From: Stefan Esser To: FreeBSD CURRENT Message-ID: Subject: [REVIEW] new function getlocalbase() - D27236 and D27237 --AvaatoqjQlBdMedbF5n0D2EyTfRB8VrWt Content-Type: multipart/mixed; boundary="------------50BAEB58100C4260A9116EAB" Content-Language: en-US This is a multi-part message in MIME format. --------------50BAEB58100C4260A9116EAB Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable I have created two Phabricator reviews for my proposed implementation of getlocalbase(): https://reviews.freebsd.org/D27236 https://reviews.freebsd.org/D27237 The first one implements getlocalbase() with quite similar semantics to getenv("LOCALBASE") which it will replace in a number of places in the base system. This implementation returns a pointer to either of: 1) getenv("LOCALBASE") 2) sysctlbyname("user.localbase", ...) 3) _PATH_LOCALBASE or "/usr/local" I had considered to copy any result of 1) or 3) into the same static buffer used to retrieve the sysctl result, but have for now implemented a version that returns the pointers as is (in case of getenv() into the environment, in case of the fall-back strings into the area for R/O strings). I'd be willing to change this to either: a) retrieve a value on the first invocation and copy it to the buffer b) retrieve a new value on each invocation and copy it to the buffer Most programs will call getlocalbase() at most once and will either construct the required path to e.g. a config file directory from it, or they will store a local copy. The return type should prevent any accidental overwriting of values at the returned address (but does not really protect e.g. the environment variable area - same as if getenv() was directly called). If returning the pointer into the environment is considered too dangerous, I'd prefer to implement variant a). A potential problem exists due the unlimited length of the string returned by getenv("LOCALBASE"), i.e. it could cause a path name longer than PATHNAMEMAX to be created. I do not want to introduce a potential error return or to silently discard superfluous data from the returned value and therefore prefer to return the pointer into the environment area without guarantees regarding the maximum length of the string pointed to. The second review replaces getenv() calls with getlocalbase() in code that already used getenv(). The code is simplified but has unchanged behavior if LOCALBASE is defined in the environment. If it is undefined, than the sysctl value or the hard-coded value is returned (and the only difference is that sysctl may cause the system wide value to be controlled without recompilation of the world). In one program the constant _PATH_LOCALBASE was concatenated to a relative file path, and in that case the same approach can be used as in the other two (with snprintf() filling a local buffer). I have not looked for other programs that should be modified to use getlocalbase(), but all affected by my recent _PATH_LOCALBASE commit are candidates ... I'd appreciate comments in the Phabricator or review or by mail. Regards, STefan --------------50BAEB58100C4260A9116EAB-- --AvaatoqjQlBdMedbF5n0D2EyTfRB8VrWt-- --NHAtD3kqYM3MFjd9Z7UrDTsfKhtZNKieQ Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAl+ysDoFAwAAAAAACgkQR+u171r99URS egf+ItpnQzslnXg2Fb5lfhPsKBrV0HsrBR9QEc80BTVSa2imkhHq6Tr942CyQru6juFz0j9n0omo nYTxulH4L5AkX2tN2mgZk+rhlGbbYifOKPCXWNmO9qj26LTgv0V54v7c7ovPVlmLUXyok9PY/G6m BrFDDdSSPOPHDlaqeTyXAOuyDKwuinuuWt1mnVcNgitQfE6GIsljxHY65d/Ze/dv7ual+hLjYIKf NOAfF6cZwFudTMtgzvnMTutpeEZBZTtu3MJoq0wmNKiiPzNgwe6uVEfNuFZAXfQgq2DAEtJjIE13 Yq6J/5gHJO71dKxzbAlDgASArwMlJ36g717TZL4h7g== =sI/5 -----END PGP SIGNATURE----- --NHAtD3kqYM3MFjd9Z7UrDTsfKhtZNKieQ--