Date: Wed, 14 Sep 2016 13:46:35 +0200 From: Ed Schouten <ed@nuxi.nl> To: twilight <pipfstarrd@openmailbox.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Is replacing alloca(3) where possible a good thing to do? Message-ID: <CABh_MK==e65R%2BEu_ZLBDiF6rKxU1mh83H2TZ9OVhDiaxbKUwig@mail.gmail.com> In-Reply-To: <3fe9ba0e-0089-a59c-a09e-8c6f8b74b6bc@openmailbox.org> References: <3fe9ba0e-0089-a59c-a09e-8c6f8b74b6bc@openmailbox.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, 2016-09-14 12:53 GMT+02:00 twilight <pipfstarrd@openmailbox.org>: > I again, > in cddl/* alloca(3) is used very intensively for creating dynamic arrays. > But, well, it's kinda obsolete and sometimes not safe and portable. > Is replacing alloca(3) with dynamic arrays a good thing? Or should > everything be left as it is? With dynamic arrays you are referring to C99's Variable-Length Arrays (VLAs), right? The advantage of C99 VLAs is that they are standardised, unlike alloca(), which is good. What I also like about them compared to alloca() is that they are easier to implement from a compiler's point of view, as they are bound to a block scope and not to a function. alloca() can be called in a loop, for example, which is quite nasty. Still, C99 VLAs and alloca() both share the problem that as there is no upper bound on the allocated space, you may easily run into stack overflows. Especially for externally-facing APIs, you may have absolutely no idea whether it's safe to allocate a buffer having a size provided by the caller. This is one of the reasons why C11 made them optional again. So the best solution is to replace any use of alloca() with malloc()/free(). That said, as you were interested in making such changes in cddl/*, I guess you'll also have to go through the process of sending those patches to Illumos. -- Ed Schouten <ed@nuxi.nl> Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABh_MK==e65R%2BEu_ZLBDiF6rKxU1mh83H2TZ9OVhDiaxbKUwig>