Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Jes Sorensen <jes.sorensen@gmail.com>
Subject: Re: [PATCH][next] zd1211rw/zd_usb.h: Replace zero-length array with
 flexible-array member
To:     "Gustavo A. R. Silva" <gustavo@embeddedor.com>,
        Kalle Valo <kvalo@codeaurora.org>
Cc:     Joe Perches <joe@perches.com>, Ulrich Kunitz <kune@deine-taler.de>,
        "David S. Miller" <davem@davemloft.net>,
        linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, Kees Cook <keescook@chromium.org>
References: <20200305111216.GA24982@embeddedor>
 <87k13yq2jo.fsf@kamboji.qca.qualcomm.com>
 <256881484c5db07e47c611a56550642a6f6bd8e9.camel@perches.com>
 <87blpapyu5.fsf@kamboji.qca.qualcomm.com>
 <1bb7270f-545b-23ca-aa27-5b3c52fba1be@embeddedor.com>
 <87r1y0nwip.fsf@kamboji.qca.qualcomm.com>
 <48ff1333-0a14-36d8-9565-a7f13a06c974@embeddedor.com>
 <021d1125-3ffd-39ef-395a-b796c527bde4@gmail.com>
 <fb3395d7-e932-10ac-1feb-ab2ceb63424e@embeddedor.com>
 <361da904-5adf-eb0c-e937-c5d2f69ac8be@gmail.com>
 <e4cfda6c-37f0-3c28-f50b-32200a67d856@embeddedor.com>
Message-ID: <9700b2c9-1029-60b0-c5d2-684bdcede354@gmail.com>
Date:   Tue, 10 Mar 2020 18:34:31 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <e4cfda6c-37f0-3c28-f50b-32200a67d856@embeddedor.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 3/10/20 6:31 PM, Gustavo A. R. Silva wrote:
> 
> 
> On 3/10/20 5:20 PM, Jes Sorensen wrote:
>> On 3/10/20 6:13 PM, Gustavo A. R. Silva wrote:
>>>
>>>
>>> On 3/10/20 5:07 PM, Jes Sorensen wrote:
>>>> As I stated in my previous answer, this seems more code churn than an
>>>> actual fix. If this is a real problem, shouldn't the work be put into
>>>> fixing the compiler to handle foo[0] instead? It seems that is where the
>>>> real value would be.
>>>
>>> Yeah. But, unfortunately, I'm not a compiler guy, so I'm not able to fix the
>>> compiler as you suggest. And I honestly don't see what is so annoying/disturbing
>>> about applying a patch that removes the 0 from foo[0] when it brings benefit
>>> to the whole codebase.
>>
>> My point is that it adds what seems like unnecessary churn, which is not
>> a benefit, and it doesn't improve the generated code.
>>
> 
> As an example of one of the benefits of this is that the compiler won't trigger
> a warning in the following case:
> 
> struct boo {
> 	int stuff;
> 	struct foo array[0];
> 	int morestuff;
> };
> 
> The result of the code above is an undefined behavior.
> 
> On the other hand in the case below, the compiles does trigger a warning:
> 
> struct boo {
> 	int stuff;
> 	struct foo array[];
> 	int morestuff;
> };

Right, this just underlines my prior argument, that this should be fixed
in the compiler.

Jes