[Mesa-dev] [PATCH 1/8] nir: Silence missing field initializer warnings for nir_src

[Ilia Mirkin]

On Mon, Dec 14, 2015 at 7:28 PM, Ian Romanick <idr at 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