[vlc-devel] [PATCH 09/12] network: io: Remove VLA usages
Steve Lhomme
robux4 at ycbcr.xyz
Thu Dec 10 08:25:17 CET 2020
On 2020-12-09 17:49, Rémi Denis-Courmont wrote:
> Le mercredi 9 décembre 2020, 17:47:18 EET Hugo Beauzée-Luyssen a écrit :
>> On Wed, Dec 9, 2020, at 4:12 PM, Rémi Denis-Courmont wrote:
>>> Le mercredi 9 décembre 2020, 11:38:42 EET Thomas Guillem a écrit :
>>> Likewise, production builds must be done with GCC or Clang again for the
>>> optimisations, as well as for licensing reasons (which we've covered
>>> multiple times in the past already).
>>
>> Who said anything about changing anything about the release builds?
>
> I don't think anybody said anything but what's the point in supporting a
> compiler that won't be used for releases?
* To have more Windows developers by making it easy for them to just
open Visual Studio and start hacking in VLC.
* To get different compiler diagnostic. Just like having clang in
addition to GCC is helping find issues GCC doesn't report.
* Possibly have more code analysis tools
>>> just to support "incomplete" C11 compilers. It's open-source so you are
>>> free to fork if you want to but I don't want to have to deal with it.
>>
>> This sounds a lot like "If you disagree with me, get out", with which I'd
>> have to disagree.
>
> I'm saying that nobody, not me, not other developers, and especially not those
> who expressed a desire to allow GCCisms/Clangisms in the code base, should
> have to deal with the extra effort from VLAs being systematically removed and
> forbidden, except those few who care to play with MSVC.
>
> I'm saying that users of non-MSVC builds should not have to suffer bugs or
> worse performance because a few want to play with MSVC without having to
> maintain their own branch.
The point of Linus and Microsoft not to support VLA is mainly
performance based. We're not getting slower code here.
More information about the vlc-devel
mailing list