[vlc-devel] [PATCH 09/12] network: io: Remove VLA usages

[Thomas Guillem]

Using VLA for this particular part of the code (http_auth) is very convenient since the size max is bounded, so it can't overflow.

Having said that, we are very close to a full support of MSVC. If we need to fix some well-written code to remove VLA, I'm OK for it. I'm convinced by Steve's arguments. Supporting MSVC can bring more developers in VLC.

Should we vote for VLA removal in VLC ? Via the TC ?

On Thu, Dec 10, 2020, at 08:25, Steve Lhomme wrote:
> 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.
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel