Kirill Smelkov <> writes:

>> > 2) alloca(), for small arrays, is used for the same reason - if we change
>> > it to xmalloc()/free() the timings get worse
>> Do you see any use of it outside compat/?
>> I thought we specifically avoid alloca() for portability.  Also we
>> do not use variable-length-arrays on the stack either, I think.
> No, no usage outside compat/ and I knew alloca and VLAs are not used in
> Git codebase for portability, and I understand alloca will be
> criticized, but wanted to start the discussion rolling.
> I've actually started without alloca, and used xmalloc/free for
> [nparent] vectors, but the impact was measurable, so it just had to be
> changed to something more optimal.
> For me, personally, alloca is ok, but I understand there could be
> portability issues (by the way, what compiler/system Git cares about
> does not have working alloca?). Thats why I propose we do the following
> 1. at configure time, determine, do we have working alloca, and define
>     #define HAVE_ALLOCA
>    if yes.
> 2. in code
>     #ifdef HAVE_ALLOCA
>     # define xalloca(size)      (alloca(size))
>     # define xalloca_free(p)    do {} while(0)
>     #else
>     # define xalloca(size)      (xmalloc(size))
>     # define xalloca_free(p)    (free(p))
>     #endif
>    and use it like
>    func() {
>        p = xalloca(size);
>        ...
>        xalloca_free(p);
>    }
> This way, for systems, where alloca is available, we'll have optimal
> on-stack allocations with fast executions. On the other hand, on
> systems, where alloca is not available, this gracefully fallbacks to
> xmalloc/free.
> Please tell me what you think.

I guess the above is clean enough, and we cannot do better than that,
if we want to use alloca() on platforms where we can.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to