<div dir="ltr"><div><div>Great. I wasn't aware of the test case. Thanks for the heads up!<br><br><br></div>Best regards,<br></div>Matheus<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 19, 2018 at 9:32 PM, Peter Hutterer <span dir="ltr"><<a href="mailto:peter.hutterer@who-t.net" target="_blank">peter.hutterer@who-t.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Jun 19, 2018 at 09:22:52PM -0300, Matheus Santana wrote:<br>
> Reviewed-by: Matheus Santana <<a href="mailto:embs@cin.ufpe.br">embs@cin.ufpe.br</a>><br>
> <br>
> The check for negatives isn't needed anymore?<br>
<br>
</span>you mean zalloc_overflow? good point. I'll leave it in though because it<br>
does test a valid error case. I've added more tests for zalloc(some large<br>
number) though.<br>
<br>
diff --git a/test/litest-selftest.c b/test/litest-selftest.c<br>
index 72bdabac..ab185d2a 100644<br>
--- a/test/litest-selftest.c<br>
+++ b/test/litest-selftest.c<br>
@@ -350,6 +350,19 @@ START_TEST(zalloc_overflow)<br>
}<br>
END_TEST<br>
<br>
+START_TEST(zalloc_max_size)<br>
+{<br>
+ /* Built-in alloc maximum */<br>
+ zalloc(1024 * 1024);<br>
+}<br>
+END_TEST<br>
+<br>
+START_TEST(zalloc_too_large)<br>
+{<br>
+ zalloc(1024 * 1024 + 1);<br>
+}<br>
+END_TEST<br>
+<br>
static Suite *<br>
litest_assert_macros_suite(<wbr>void)<br>
{<br>
@@ -415,7 +428,9 @@ litest_assert_macros_suite(<wbr>void)<br>
suite_add_tcase(s, tc);<br>
<br>
tc = tcase_create("zalloc ");<br>
+ tcase_add_test(tc, zalloc_max_size);<br>
tcase_add_test_raise_signal(<wbr>tc, zalloc_overflow, SIGABRT);<br>
+ tcase_add_test_raise_signal(<wbr>tc, zalloc_too_large, SIGABRT);<br>
suite_add_tcase(s, tc);<br>
<br>
return s;<br>
<br>
Cheers,<br>
Peter<br>
<div class="HOEnZb"><div class="h5"><br>
> <br>
> On Tue, Jun 19, 2018 at 8:44 PM, Peter Hutterer <<a href="mailto:peter.hutterer@who-t.net">peter.hutterer@who-t.net</a>><br>
> wrote:<br>
> <br>
> > The ssize_t cast upsets coverity for some reason but we can be a lot more<br>
> > restrictive here anyway. Quick analysis of the zalloc calls in the test<br>
> > suite<br>
> > show the largest allocation is 9204 bytes.<br>
> ><br>
> > Let's put a cap on for one MB, anything above that is likely some memory<br>
> > corruption and should be caught early.<br>
> ><br>
> > Signed-off-by: Peter Hutterer <<a href="mailto:peter.hutterer@who-t.net">peter.hutterer@who-t.net</a>><br>
> > ---<br>
> > src/libinput-util.h | 4 +++-<br>
> > 1 file changed, 3 insertions(+), 1 deletion(-)<br>
> ><br>
> > diff --git a/src/libinput-util.h b/src/libinput-util.h<br>
> > index 8c67dcbd..4f60e8ea 100644<br>
> > --- a/src/libinput-util.h<br>
> > +++ b/src/libinput-util.h<br>
> > @@ -142,7 +142,9 @@ zalloc(size_t size)<br>
> > {<br>
> > void *p;<br>
> ><br>
> > - if ((ssize_t)size < 0)<br>
> > + /* We never need to alloc anything even near one MB so we can<br>
> > assume<br>
> > + * if we ever get above that something's going wrong */<br>
> > + if (size > 1024 * 1024)<br>
> > abort();<br>
> ><br>
> > p = calloc(1, size);<br>
> > --<br>
> > 2.17.1<br>
</div></div></blockquote></div><br></div>