From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52391) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQuoL-00081L-S8 for qemu-devel@nongnu.org; Wed, 03 Feb 2016 05:37:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQuoK-0000bK-ND for qemu-devel@nongnu.org; Wed, 03 Feb 2016 05:37:21 -0500 Date: Wed, 3 Feb 2016 11:37:10 +0100 From: Kevin Wolf Message-ID: <20160203103710.GA4754@noname.redhat.com> References: <1CF37786-9AAA-4E5E-B571-DE20E7A463EB@gmail.com> <20160202171606.GM18461@redhat.com> <72A30A67-5846-4835-B8D2-B7F545F76C0B@gmail.com> <56B1039B.5020104@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <56B1039B.5020104@redhat.com> 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: Eric Blake Cc: Programmingkid , qemu-devel qemu-devel , Qemu-block Am 02.02.2016 um 20:29 hat Eric Blake geschrieben: > On 02/02/2016 10:28 AM, Programmingkid wrote: >=20 > >> 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.= =20 >=20 > 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. Just let me add that while it's probably harmless here in .bdrv_open(), other paths in the block layer which run in a coroutine have a much more limited stack size and the danger of stack overflows is very real there. Kevin