Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH][next] xfs: Replace one-element arrays with flexible-array
 members
To:     "Darrick J. Wong" <djwong@kernel.org>
Cc:     "Gustavo A. R. Silva" <gustavoars@kernel.org>,
        Dave Chinner <david@fromorbit.com>, linux-xfs@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
References: <20210302150558.GA198498@embeddedor>
 <20210309174212.GV3419940@magnolia>
 <8bf7e1d2-e2d4-c56f-cd04-0045dc4c7e2f@embeddedor.com>
 <20210309212643.GZ3419940@magnolia>
From:   "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Message-ID: <6cd7c00a-a49c-41f9-06cb-e3123bb32d6c@embeddedor.com>
Date:   Tue, 9 Mar 2021 16:03:56 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <20210309212643.GZ3419940@magnolia>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 3/9/21 15:26, Darrick J. Wong wrote:
>>> It seems to work all right for casted NULL pointers, and then we get all
>>> the typechecking and multiplication overflow checking, e.g.:
>>>
>>> 	size_t len64 = struct_size((struct xfs_efi_log_format_32 *)NULL,
>>> 				efi_extents src_efi_fmt->efi_nextents);
>> Yeah; in that case, what do you think about casting 0, instead of NULL:
>>
>>        uint len32 = struct_size((xfs_efi_log_format_32_t *)0, efi_extents,
>>                                 src_efi_fmt->efi_nextents);
>>        uint len64 = struct_size((xfs_efi_log_format_64_t *)0, efi_extents,
>>                                 src_efi_fmt->efi_nextents);
> I don't have a preference either way, either here or for the half-dozen
> more of these scattered elsewhere in the file.

OK. I'll send v2, shortly

Thanks for the feedback!
--
Gustavo