Thread (22 messages) 22 messages, 5 authors, 2020-12-03

Re: [PATCH 3/6] fixup! reftable: rest of library

From: Han-Wen Nienhuys <hidden>
Date: 2020-12-01 11:11:14

On Tue, Dec 1, 2020 at 11:26 AM Jeff King [off-list ref] wrote:
On Sat, Nov 28, 2020 at 06:44:35AM +0000, Johannes Schindelin via GitGitGadget wrote:
quoted
From: Johannes Schindelin <redacted>

0-sized arrays are actually not portable.
Definitely.
quoted
 static void test_sizes_to_segments_empty(void)
 {
-     uint64_t sizes[0];
+     uint64_t sizes[1];

      int seglen = 0;
      struct segment *segs =
-             sizes_to_segments(&seglen, sizes, ARRAY_SIZE(sizes));
+             sizes_to_segments(&seglen, sizes, 0);
      EXPECT(seglen == 0);
      reftable_free(segs);
I think passing:

  sizes_to_segments(&seglen, NULL, 0);

may make the code more obvious. Unlike system functions like memcpy(),
we can be assured of whether our functions avoid looking at a
zero-length array (and size_to_segments does follow that rule).

  This function, of course, is nonsense that real code would not do, and
This test was added because 'real' code did this. In particular, if
you initialize a stack of reftables, the stack has zero elements. The
test was for the following bugfix

https://github.com/google/reftable/commit/b2e42ecb54e413e494c1fcc13c21e24422645007

Changing the array size to 1 here also prevents Valgrind to mark a
regression as a OOB write.

-- 
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--
Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help