Date: Sun, 15 Feb 2015 19:40:01 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: John-Mark Gurney <jmg@funkthat.com> Cc: src-committers@freebsd.org, Ian Lepore <ian@freebsd.org>, svn-src-all@freebsd.org, Pedro Giffuni <pfg@freebsd.org>, Gleb Smirnoff <glebius@freebsd.org>, Bruce Evans <brde@optusnet.com.au>, svn-src-head@freebsd.org Subject: Re: svn commit: r278737 - head/usr.sbin/flowctl Message-ID: <20150215185431.M1467@besplex.bde.org> In-Reply-To: <20150215074419.GB1953@funkthat.com> References: <201502132357.t1DNvKda075915@svn.freebsd.org> <20150214193210.N945@besplex.bde.org> <20150214181508.GL15484@FreeBSD.org> <1423938828.80968.148.camel@freebsd.org> <54DFA7CC.20305@FreeBSD.org> <20150215162553.L977@besplex.bde.org> <20150215074419.GB1953@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 14 Feb 2015, John-Mark Gurney wrote:
> Bruce Evans wrote this message on Sun, Feb 15, 2015 at 17:53 +1100:
>> On Sat, 14 Feb 2015, Pedro Giffuni wrote:
>>
>>> On 02/14/15 13:33, Ian Lepore wrote:
>>>> On Sat, 2015-02-14 at 21:15 +0300, Gleb Smirnoff wrote:
>>>>> On Sat, Feb 14, 2015 at 08:46:58PM +1100, Bruce Evans wrote:
>>>>> B> Using VLAs and also the C99 feature of declarations anwhere, and
>>>>> extensions
>>>>> B> like __aligned(), we can almost implement a full alloca() using the
>>>>> fixed
>>>>> B> version of this change:
>>>>> B>
>>>>> B> /*
>>>>> B> * XXX need extended statement-expression so that __buf doesn't go out
>>>>> B> * of scope after the right brace.
>>>>> B> */
>>>>> B> #define my_alloca(n) __extension__ ({
>>>>> B> /* XXX need unique name. */ \
>>>>> B> char __buf[__roundup2((n), MUMBLE)] __aligned(MUMBLE); \
>>>>> B> \
>>>>> B> (void *)__buf; \
>>>>> B> })
>>>>>
>>>>> I like this idea. But would this exact code work? The life of
>>>>> __buf is limited by the code block, and we exit the block
>>>>> immediately. Wouldn't the allocation be overwritten if we
>>>>> enter any function or block later?
>
> Could this just be changed to something like:
> struct ng_mesg ng_mesg[(SORCVBUF_SIZE + sizeof(struct ng_mesg) - 1) /
> sizeof(struct ng_mesg)];
>
> It might allocate a few extra bytes, but no more than 55, and gets
> alignment correct w/o lots of other hacks...
I already gave this version, with
(SORCVBUF_SIZE + sizeof(struct ng_mesg) - 1) / sizeof(struct ng_mesg)
spelled as
howmany(SORCVBUF_SIZE, sizeof(*ng_mesg)).
Even with the better spelling, it is less clear than using alloca().
Using malloc() would be equally clear to using alloca(), except it would
take even more code unless all of error checking, error handling and
deallocation were omitted. Presumably the unnecessary complications for
that are the reason why malloc() wasn't used originally. However, it
may be considered a style bug to use alloca() when almost everything
else laboriously uses malloc().
"alloca(" occurs in 453 lines in /usr/src/. 110 not counting cddl,
contrib, crypto or sys. 35 of the 110 are in jail; 10 in libjail; 12
in ctm; 7 in ppp; 8 in pppoed. That leaves 38. The only applications
in these 38 are swapon, rpcbind, jls, flowctl and vidcontrol. Some
of these could probably use VLAs. E.g., vidcontrol uses alloca()
just twice, for char buffers. It has laborious error checking and
handling after each. But the error checking is essentially useless
since the libc alloca() that can return NULL is never used. More
critical/security-related applications like jail of course don't
have the error checking or handling.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150215185431.M1467>