On Fri, Mar 02, 2018 at 03:03:10AM -0800, Christopher Li wrote:
>
> That is just the memory operation convert to pseudo.
> Sparse find out "b" has no dominating store (uninitialized), so
> it just replace it with 0 value.
>
> The 64 bit one is b, the long type.
> The 32 bit one is c, the int type.
>
> I already find out the place cause it:
> The fix is here:
Even with this fix I see others regressions.
Also the current top patch (which I saw on the ML) and
whose purpose was to fix the crash, will create a
strange situation with code like:
struct s {
int r;
char buf[<somenumbercloseto65535>];
};
struct s *d, *s;
...
*d = *s;
Where pseudo->size will be truncated to 16bit and
won't correspond to the real size of the corresponding
object. I don't think a 64K array is something extraordinary
(of course the current 16bit can be extended to 24bit).
This pseudo-size series need much more care, love and testing.
I'll thus revert it for now and the series can be resubmitted
without precipitation when the problems will have been addressed.
-- 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
