[vlc-devel] [PATCH 05/12] Replace variable-length arrays by calls to alloca() for C90 compliance.

Rémi Denis-Courmont remi at remlab.net
Mon Dec 2 13:01:52 CET 2013


On Mon, 2 Dec 2013 10:45:21 +0100, Felix Abecassis
<felix.abecassis at gmail.com> wrote:
> 2013/11/30 Rémi Denis-Courmont <remi at remlab.net>:
>> Le samedi 30 novembre 2013, 15:59:19 Felix Abecassis a écrit :
>>> C89 and C90 are the same.
>>> VLAs were added in C99 so removing them actually helps C89/C90
>>> compliance.
>>
>> That's not true. alloca() is not in C89, even if you want to call it
>> C90. It
>> is non-standard and thus using it cannot help standard compliance.
> I meant: not using VLAs helps C89/C90 compliance.

Sorry but that is a stupid claim. The whole VLC code base is reliant on
C99 in many different places and ways. There is no way in hell that it is
ever going to revert to C89.

>> alloca() is _not_ in C11, and is not supported by all _conforming_
>> compilers.
> You are right, but we might achieve better portability by using
> alloca() instead of VLAs; even if it is not standard.

I don't think so. The current code is mostly syntactically portable to C99
and even more so to C11, with a few known issues such as NULL for %s
format, #error and #warning. Adding alloca() makes it less portable.

>> Worst yet, alloca() does not an equivalent or a superset of VLAs
>> functionally speaking.
> 
>> And relatively speaking, alloca() is far worse than VLAs.
> Could you elaborate on that? Why is it worse than VLAs?

And how would it better than VLAs?
The main argument on the evilness of VLAs is the (intrinsic) lack of error
checking in case of stack overflow. alloca() is even more prone to that
problem since its allolcations have a larger scope. That is also one of the
reason why alloca() is _not_ a drop-in replacement for VLAs.

-- 
Rémi Denis-Courmont
Sent from my collocated server



More information about the vlc-devel mailing list