On Mon, Dec 14, 2015 at 7:28 PM, Ian Romanick <i...@freedesktop.org> wrote:
> On 12/14/2015 03:38 PM, Ilia Mirkin wrote:
>> It's a pretty standard feature of compilers to init things to 0 and
>> not have the full structure specified like that... what compiler are
>> you seeing these with? Can we just fix the glitch with a
>> -Wno-stupid-warnings?
>
> I have observed this with several versions of GCC.
>
> In C, you can avoid this with a trailing comma like:
>
> #define NIR_SRC_INIT (nir_src) { { NULL }, }
>
> However, nir.h is also used in some C++ code where that doesn't help.
>
> To be honest, I'm not a big fan of these macros. Without C99 designated
> initalizers, maintaining initializers like these (or the ones in
> src/glsl/builtin_variables.cpp) is a real pain. We can't use those, and
> we can't use C++ constructors. We have no good options available. :(
>
> I thought about replacing them with a static inline function that
> returns a zero-initialized struct. The compiler should generate the
> same code. However, that doesn't work with uses like those in patch 3.
>
> I'm also a little curious why you didn't raise this issue when I sent
> these patches out in August. I removed the patch from the series that
> you objected to back then.
I have absolutely no recollection of any of that. Perhaps I saw "nir"
and thought to myself, "don't care, let them do whatever, this won't
ever affect me". Which is a sentiment I'm happy to continue with, by
the way.
I know that doing
x = {}
is a gcc extension, but I thought that {0} should always work (with
enough {} nesting in case the first element is a struct). Perhaps it
doesn't in C++? I could believe that, although I'd be surprised.
Anyways, didn't mean to stir the pot too much, just thought there
might be a simpler way out of all this.
Cheers,
-ilia
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
