On Wed, Jun 20, 2018 at 09:12:54AM +0200, Jan Engelhardt wrote:
> On Wednesday 2018-06-20 02:22, Matheus Santana wrote:
>
> >Reviewed-by: Matheus Santana
> >
> >The check for negatives isn't needed anymore?
>
> It indeed is not, since a (size_t)-1 is generally greater than 1048576.
still good t
On Wednesday 2018-06-20 02:22, Matheus Santana wrote:
>Reviewed-by: Matheus Santana
>
>The check for negatives isn't needed anymore?
It indeed is not, since a (size_t)-1 is generally greater than 1048576.
> Let's put a cap on for one MB, anything above that is likely some memory
> cor
Great. I wasn't aware of the test case. Thanks for the heads up!
Best regards,
Matheus
On Tue, Jun 19, 2018 at 9:32 PM, Peter Hutterer
wrote:
> On Tue, Jun 19, 2018 at 09:22:52PM -0300, Matheus Santana wrote:
> > Reviewed-by: Matheus Santana
> >
> > The check for negatives isn't needed anymor
On Tue, Jun 19, 2018 at 09:22:52PM -0300, Matheus Santana wrote:
> Reviewed-by: Matheus Santana
>
> The check for negatives isn't needed anymore?
you mean zalloc_overflow? good point. I'll leave it in though because it
does test a valid error case. I've added more tests for zalloc(some large
nu
Reviewed-by: Matheus Santana
The check for negatives isn't needed anymore?
On Tue, Jun 19, 2018 at 8:44 PM, Peter Hutterer
wrote:
> The ssize_t cast upsets coverity for some reason but we can be a lot more
> restrictive here anyway. Quick analysis of the zalloc calls in the test
> suite
> show
The ssize_t cast upsets coverity for some reason but we can be a lot more
restrictive here anyway. Quick analysis of the zalloc calls in the test suite
show the largest allocation is 9204 bytes.
Let's put a cap on for one MB, anything above that is likely some memory
corruption and should be caugh
