[vlc-devel] [PATCH 09/12] network: io: Remove VLA usages
remi at remlab.net
Wed Dec 9 16:12:18 CET 2020
Le mercredi 9 décembre 2020, 11:38:42 EET Thomas Guillem a écrit :
> MSCV is a recent compiler, and we should support it
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.
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).
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).
However, I don't want to make the code slower, buggier and more complicated
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.
> (lot of open-source projects support mingw and msvc).
Not only don't I see why we should care. But I do recall several active VLC
developers arguing that we should just cross the rubicon back again and use
Clang-compatible GCCisms, or even use Clangisms. Indeed, as much as I am
loathe to drop C11, I can only acknowledge that it would help with macros, for
And we've also had developers push patches that plainly contradict C11. TO be
fair, VLC never supported a pure C11 environment; it has always required not
only "optional" C11 features, but plenty of POSIX or OS-specific stuff on top.
tl;dr: we can't have it both ways.
> Some other projects tend to remove VLA usage :
The Linux kernel is running on bare metal and written in free-standing GNU
C89, with a completely custom memory model and atomic variable API. VLC is
application code, written in hosted ISO C11, with the standard memory model
and atomic variables. The comparison is as vain as it gets.
And as for VLAs, the Linux kernel uses typically 8 KiB stacks in physical
memory, and has hard real-time use cases. I can see why you wouldn't want VLA
in such environment. Meanwhile, VLC has, what, 2 MiB stacks in virtual memory.
Last time I tried couldn't even run with stacks less than 128 KiB on 386,
regardless of VLAs. It's also nowhere near real-time-capable.
More information about the vlc-devel