On 07.08.2019, at 19:39, Daniel Kolesa <dan...@octaforge.org> wrote: > While this technically compiles in current ffmpeg, this is only > because ffmpeg is compiled in strict ISO C mode, which disables > the builtin 'vector' keyword for AltiVec/VSX. Instead this gets > replaced with a macro inside altivec.h, which defines vector to > be actually __vector, which accepts random types. > > Normally, the vector keyword should be used only with plain > scalar non-typedef types, such as unsigned int. But we have the > vec_(s|u)(8|16|32) macros, which can be used in a portable manner, > in util_altivec.h in libavutil. > > This is also consistent with other AltiVec/VSX code elsewhere in > the tree.
I see the consistency argument, but otherwise it really doesn't sound convincing. I don't think the intend to support compiling with -std=gnu11 either way, so not sure we should care about that. And not allowing typedef'd type seems utterly silly and against any expected C behaviour that for simple maintenance reasons I don't think we want this long-term. As far as I remember switching to __vector everywhere is not really an option either though because some compilers do not accept that? I don't strictly object to the change, it just doesn't really feel like a truly good path forward long-term. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
