On 3/10/20 5:15 PM, Joe Perches wrote: > On Tue, 2020-03-10 at 17:13 -0500, Gustavo A. R. Silva wrote: >> >> 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@xxxxxxxxxxxxxx> 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. > > As far as I can tell, it doesn't actually make a difference as > all the compilers produce the same object code with either form. > That's precisely why we can implement these changes, cleanly(the fact that the compiler produces the same object code). So, the resulting object code is not the point here. -- Gustavo
