[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: disk/mdraid1x_linux.c:181:15: warning: array subscript ...

From: Michael Chang
Subject: Re: disk/mdraid1x_linux.c:181:15: warning: array subscript ...
Date: Thu, 26 Mar 2020 11:08:54 +0800
User-agent: Mutt/1.10.1 (2018-07-13)

On Wed, Mar 25, 2020 at 12:13:49PM +0100, Thomas Schmitt wrote:
> Hi,
> Michael Chang wrote in patch 2/2:
> > ../../grub-core/fs/zfs/zfs.c:2263:44: error: array subscript '<unknown>' is
> > outside the bounds of an interior zero-length array 'grub_uint16_t[0]' {aka
> > 'short unsigned int[0]'} [-Werror=zero-length-bounds]
> > [...]
> > The l_hash[0] is apparnetly an interior member to the enclosed structure
> > [...] the l_entries[0] is used to get proper alignment to access leaf chunks
> That's what i call a dirty hack.
> I wonder what gcc would say to a union of [0]-sized arrays as last
> member of the struct type:
>   struct typedef struct zap_leaf_phys {
>         ...
>         union {
>                 grub_uint16_t l_hash[0];
>                 grub_properly_aligned_t l_entries[0];
>         } l_;
>   } zap_leaf_phys_t;

As far as I know the union will store different types in same memory
location, thus the allocation is determined by the largest member in the
union, so does the padding has to meet the alignment requirement by the
largest member.

So in this case l_hash[0] (2 bytes) will be aligned to
grub_properly_aligned_t (8 bytes) and for the result is desired or not
really depends on what you want to achieve.

> Mine likes such a gesture, but it is way behind in respect to modern bitrot.

Admittedly that would produce much more readable code, but it is just
not work for the extraordinary case here because of specific requirment
to the alignment.

> So in the end, your patch looks like the solid and unambiguous way to
> implement what is desired.
> > It would be great if you can help to test patch to solve the build
> > problem for gcc-10 in your system or not.
> Due to lack of modernity i can only contribute statements that the
> concepts and motivations of your two patches look good to me.
> (I also lack the occasion to test the two use cases.
>  Just lurking here for grub-mkrescue issues, where i provide the last stage
>  of packing up the ISO image.)

The grub-mkrescue is a gem, it never disappoints me whenever I need it.

Thanks a lot for your feedback.


> Have a nice day :)
> Thomas
> _______________________________________________
> Grub-devel mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]