lkml.org 
[lkml]   [2020]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH][next] zd1211rw/zd_usb.h: Replace zero-length array with flexible-array member
From
Date


On 3/10/20 5:07 PM, Jes Sorensen wrote:
> On 3/10/20 5:52 PM, Gustavo A. R. Silva wrote:
>>
>>
>> On 3/10/20 8:56 AM, Kalle Valo wrote:
>>> + jes
>>>
>>> "Gustavo A. R. Silva" <gustavo@embeddedor.com> writes:
>>>>> I wrote in a confusing way, my question above was about the actual patch
>>>>> and not the the title. For example, Jes didn't like this style change:
>>>>>
>>>>> https://patchwork.kernel.org/patch/11402315/
>>>>>
>>>>
>>>> It doesn't seem that that comment adds a lot to the conversation. The only
>>>> thing that it says is literally "fix the compiler". By the way, more than
>>>> a hundred patches have already been applied to linux-next[1] and he seems
>>>> to be the only person that has commented such a thing.
>>>
>>> But I also asked who prefers this format in that thread, you should not
>>> ignore questions from two maintainers (me and Jes).
>>>
>>
>> I'm sorry. I thought the changelog text had already the proper information.
>> In the changelog text I'm quoting the GCC documentation below:
>>
>> "The preferred mechanism to declare variable-length types like struct line
>> above is the ISO C99 flexible array member..." [1]
>>
>> I'm also including a link to the following KSPP open issue:
>>
>> https://github.com/KSPP/linux/issues/21
>>
>> The issue above mentions the following:
>>
>> "Both cases (0-byte and 1-byte arrays) pose confusion for things like sizeof(),
>> CONFIG_FORTIFY_SOURCE."
>>
>> sizeof(flexible-array-member) triggers a warning because flexible array members have
>> incomplete type[1]. There are some instances of code in which the sizeof operator
>> is being incorrectly/erroneously applied to zero-length arrays and the result is zero.
>> Such instances may be hiding some bugs. So, the idea is also to get completely rid
>> of those sorts of issues.
>
> 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.

Thanks
--
Gustavo

\
 
 \ /
  Last update: 2020-03-10 23:25    [W:0.074 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site