From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55601) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQgdw-0005JQ-59 for qemu-devel@nongnu.org; Tue, 02 Feb 2016 14:29:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQgdv-0001LU-3X for qemu-devel@nongnu.org; Tue, 02 Feb 2016 14:29:40 -0500 References: <1CF37786-9AAA-4E5E-B571-DE20E7A463EB@gmail.com> <20160202171606.GM18461@redhat.com> <72A30A67-5846-4835-B8D2-B7F545F76C0B@gmail.com> From: Eric Blake Message-ID: <56B1039B.5020104@redhat.com> Date: Tue, 2 Feb 2016 12:29:31 -0700 MIME-Version: 1.0 In-Reply-To: <72A30A67-5846-4835-B8D2-B7F545F76C0B@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bkLR3rPmbdiTouuB4AAN4MKOsibr2aTSm" Subject: Re: [Qemu-devel] ping: [PATCH v13] block/raw-posix.c: Make physical devices usable in QEMU under Mac OS X host List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Programmingkid , "Daniel P. Berrange" Cc: Kevin Wolf , qemu-devel qemu-devel , Qemu-block This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bkLR3rPmbdiTouuB4AAN4MKOsibr2aTSm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/02/2016 10:28 AM, Programmingkid wrote: >> Whats the rationale here ? Using pre-allocated fixed >> length arrays is pretty bad practice in general, but >> especially so for filenames >=20 > With an automatic variable there is no worry about when to release it. = Yeah, but it comes with the downside of having to worry about exhausting stack space (there are platforms where MAXPATHLEN is intentionally undefined [hello, GNU Hurd]), or with the downside of arbitrary limitations. And at the same time, MAXPATHLEN is usually wasteful - allocating 1k or 4k of stack to store what is typically less than 100 bytes is dumb. Really, storing file names in fixed length arrays is better off to avoid, and just get used to dynamic management. > Having to decide when and where to free memory is eliminated with autom= atic variables. That's a crutch. Anyone who can't properly manage dynamic memory allocation, and sticks to only static allocation out of convenience, is a rather lazy programmer. > The code looks cleaner without all the g_free()'s. It also might elimin= ate possible memory leaks. Whether eliminating g_free() looks cleaner is subjective (I actually find g_free cleaner than foo[MAXPATHLEN]). And the whole point of code review is to let others ensure you don't introduce memory leaks. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --bkLR3rPmbdiTouuB4AAN4MKOsibr2aTSm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWsQObAAoJEKeha0olJ0Nq3EcH/R45MMysGrCUN4BI2smprJvh Hw7Ja/vjoFbSavUELPpT7581209SeTxnj4NWUeQ5fsGSDubnt2hijZBxlHbAnnrp I8Ac0lt1+X+C8f2+M5DHvI0VDOCA6Kt9meLNBj2ghf3V3EgGKQVmYAU8eIVO+Y4+ z/yWTRLyRQjcAlfBwoyWDCauRXGvCRQrZaPIjbMNqCH/jmg8iaHKklmNIu01qnZM h1fEIv4/wu+hTEEPztQ7BP+YnI/FRWgX7fW+Q/BtvK8GxtWQ35UiLiCdsNW8uWYn CD0yUqd2qCOEZknlqwlSV58pxINCsGDWT5jelpnLqkr4vLo3HN1m9KHdi9fRDLc= =+/nZ -----END PGP SIGNATURE----- --bkLR3rPmbdiTouuB4AAN4MKOsibr2aTSm--