Re: [PATCH] mkimage: fix build regression in grub_mkimage_load_image

[Daniel Kiper]

On Tue, Mar 06, 2018 at 05:22:00PM -0500, Peter Jones wrote:
> On Tue, Mar 06, 2018 at 01:38:58PM -0800, Eric Snowberg wrote:
> > The grub_mkimage_load_image function (commit 7542af6, mkimage: refactor a 
> > bunch
> > of section data into a struct.) introduces a build regression on SPARC:
> >
> >   cc1: warnings being treated as errors
> >   In file included from util/grub-mkimage32.c:23:
> >   util/grub-mkimagexx.c: In function 'grub_mkimage_load_image32':
> >   util/grub-mkimagexx.c:1968: error: missing initializer
> >   util/grub-mkimagexx.c:1968: error: (near initialization for 
> > 'smd.sections')
> >   make[2]: *** [util/grub_mkimage-grub-mkimage32.o] Error 1
> >
> > Initialize the entire section_metadata structure.
>
> I'm not against this fix.

Applied as the quick fix. Thanks a lot!

> That said, looking at the longer term: how do we have this problem
> still?  Or: can we please add one of -std={gnu99,gnu11}[0] by default
> instead of continuing to "fix" things this way?  The C standard has had
> this to say about initializer-lists for 19 years now, and even longer in
> drafts:
>
> 19 The initialization shall occur in initializer list order, each
>    initializer provided for a particular subobject overriding any
>    previously listed initializer for the same subobject; all subobjects
>    that are not initialized explicitly shall be initialized implicitly
>    the same as objects that have static storage duration.
>
> The compiler most of us use added this functionality when most of us
> were in grade school, and the compiler the rest of us use wasn't written
> yet when this part of the C standard was.  I strongly suspect every
> compiler we care about works just fine with that if we just ask it to.
>
> Can we eliminate having this issue instead of continuing to have to
> "fix" the *better* form of this code piecemeal every time someone
> forgets we're hobbled in this particular way?

Peter, if you could prepare a patch(es) and test it/them on i386, x86_64,
ARM (CC Leif?) and SPARC (CC Eric?) then I am happy to get it/them.

Thanks,

Daniel