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

Rémi Denis-Courmont remi at remlab.net
Fri Dec 11 11:28:43 CET 2020

Le vendredi 11 décembre 2020, 10:51:56 EET Steve Lhomme a écrit :
> On 2020-12-10 16:44, Rémi Denis-Courmont wrote:
> > Le jeudi 10 décembre 2020, 09:11:25 EET Steve Lhomme a écrit :
> >> We could very well support MSVC (again) now that they support all
> >> mandatory C11 features [1].
> > 
> > That link says that they do not support all mandatory features. It also
> "All the required features of C11 and C17 are supported." +
> "there is currently no support for any C11 optional features"

That same document implies that the following 2-liners of pure nonoptional 
hosted C11 is not supported:

#include <stdlib.h>
int main(void) { free(aligned_alloc(1, 1); return 0; }

That makes it a non-conformant compiler. You're just nitpicking and contriving 
the spec. That's not how conformance works.

> * VLA we don't really need.

We do as already explained.

There was a decision to *upgrade* to C++11 then C11. There never was a 
decision to downgrade from C99 by cropping what C11 made optional. There's 
been a lot of pretexts about how this is a conformance problem in VLC code, 
but really this is all MSVC problems. It's a case of two people wanting to 
force everybody else to use to change the coding standards agreed by the 
community for their own personal wishes.

Well no. This project does not work your way or the highway.

If your compiler follows the spec, good for you. If it does not, it's not the 
community's problem. And if, or rather when, GCC and Clang support C++2x (or 
C2X) and somebody wants to use it, we should switch over, regardless of what 
ARMVCT, ICC, MSVC, SUNCC or whatever other prioritary compiler support or not. 
As we've always been doing.

 * atomics I've had a corresponding file (code that used to be in VLC)

> [1] to hide the fact MSVC doesn't have it. This is not really an issue.

In other words:
1) MSVC does not fill VLC requirements,
2) it is your problem to deal with, if you wish to use MSVC anyway.

> * threads.h we only seem to use it for _Thread_local but we already have
> the corresponding workaround for MSVC [2]. So this is not an issue
> either. So much that clang doesn't have it either.

Threads are a dependency of atomics and memory ordering. We rely on them 
heavily, especially the later which is necessary for pretty much the entirety 
of the VLC code to work in multithreaded environment.

Rémi Denis-Courmont

More information about the vlc-devel mailing list