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

[Rémi Denis-Courmont]

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 :
> > > MSCV is a recent compiler, and we should support it
> > 
> > No?
> > 
> > The pragmatic reality is that development/debug builds must be done with
> > GCC or Clang to get all the diagnostics, test all the optimisations and
> > simply to keep your sanity and not keep hitting accidental compatibility
> > regressions.

> Says who?!

Says the project history as shown by the vlc.git block chain. The code base is 
full of GCC- and/or clang-specific diagnostics, optimisations and/or features. 
It's also full of code that would not compile, or miscompile, or other 
compilers (or older versions of those two).

> Why should we prevent VLC from being built on MSVC if it can?

I don't think we should and I don't think anybody thinks we should. But it 
can't be built on VLC, so that's moot.

> > 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?

I mean, research aside. Research is not a justification for making the codebase 
worse for everybody.

> > Considering that different people have different, and somtimes
> > conflicting, goals
> > and opinions, I do like to use the full C11 specification as an
> > *objective*
> > reference. I also think people should be allowed to use other complete
> > C11
> > compilers for research purpose. But I do note that some developers here
> > ostensibly don't even agree with that (see below).
> 
> MSVC 16.8 is C11 compliant.

So maybe it's compliant with free-standing C11 and no options. And then what? 
VLC needs hosted C11 with atomics, VLAs, IEEE floats, Unicode, 8-bit 
characters, two-complements, etc. And a whole lot of non-ISO extensions on 
top.

> > 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.

I never said anybody should get out. If maintaining a fork means getting out 
to you, that's on you.

> For the sake of clarity, are you opposed to removing VLAs from VLC's source
> code? If not, let's have a calm discussion about what issues are introduced
> by this patchset, because for now I genuinely don't see them.

I am opposed to forbidding VLAs in general, and I am opposed to removing VLAs 
in the specific corner cases where fixed-size arrays are not practical and 
variable-length arrays cannot cause stack overflow.

-- 
Rémi Denis-Courmont