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

[Alexandre Janniaux]

Hi,

Instead of adding failure here, maybe the net_* abstraction
can be changed to adapt to that, for instance with a more
high-level abstraction like traditional evloops (much like
the epoll model with add/select/remove operations).

There still would be a failure case, but it would not be
handled at the net_accept() location, but at the "net_add()"
location instead, where allocation would take place, much
like the ENOMEM failure in epoll_ctl syscall.

I agree that replacing VLA here as-is is debatable, but I'm
in favor of removing VLA usage too.

Regards,
--
Alexandre Janniaux
Videolabs

On Thu, Dec 10, 2020 at 10:19:07AM +0100, Thomas Guillem wrote:
> 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
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel