On Thu, Dec 28, 2017 at 09:44:25PM +0000, Dibyendu Majumdar wrote: > Hi Luc, > > On 28 December 2017 at 21:40, Luc Van Oostenryck > <luc.vanoostenryck@xxxxxxxxx> wrote: > > On Thu, Dec 28, 2017 at 09:20:41PM +0000, Dibyendu Majumdar wrote: > >> On 28 December 2017 at 21:19, Luc Van Oostenryck > >> <luc.vanoostenryck@xxxxxxxxx> wrote: > >> > On Thu, Dec 28, 2017 at 09:02:27PM +0000, Dibyendu Majumdar wrote: > >> >> Previous thread on this issue: > >> >> > >> >> https://www.spinics.net/lists/linux-sparse/msg05427.html > >> > > >> > Ah yes, sorry, I forgot you already specifically reported this one. > >> > > >> > It should be fixed now. > >> > > >> > >> Well last time I thought the view was that a fix was not needed? What's changed? > > > > Another case which led to a better understanding of the situation. > > > > I understood that the correct solution was for the symbol to hold the size. > > https://www.spinics.net/lists/linux-sparse/msg05442.html > https://www.spinics.net/lists/linux-sparse/msg05444.html The situation is: 1) yes, all what's really needed is present in SYM_NODE::bit_size 2) but some part of the code use SYM_ARRAY::bit_size or SYM_ARRAY::array_size 3) the implicit size of unsized arrays is really a special case that's doesn't follow the normal handling of SYM_NODE and the corresponding base type 2) the SYM_ARRAY must not be updated because it can be shared between several nodes with different size (like in the testcase I joined with the fix) So duplicating the SYM_ARRAY to unshare it then updating it seems to be what is needed although I don't find it very clean. Not all of this was understood in March. Regards, Luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
