On Fri, Mar 2, 2018 at 10:34 AM, Luc Van Oostenryck
<luc.vanoostenryck@xxxxxxxxx> wrote:
>
> 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).
Are you kidding me? PSEUDO_VAL only cover what ever
is able to store in side pseudo->value, which is "long long". 16
bit is plenty enough.
struct *d is not freaking going to store in PSEUDO_VAL period.
I don't know what you are smoking. You'd better explain this
pseudo->size going to exceed 16 bit thing if you think that is
trigger-able in the current code.
> 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.
What test case do you still have? Can you submit some test case
expose the problem rather than talk about there is some problem.
That is FUD.
We should keep it on a branch so others can run test on it to
expose problems. It is a chicken and egg problem.
Chris
--
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
