On 10/20/25 16:26, Peter Maydell wrote:
+#define _GNU_SOURCE

Why do we need to define this now ?

'mremap' isn't POSIX, so on Linux at least is only exposed if _GNU_SOURCE is defined.
 >> -    fprintf(stderr, "FAILED at %s:%d\n", __FILE__, __LINE__); \
+    fprintf(stderr, " FAILED at %s:%d\n", __FILE__, __LINE__); \

I think that this is trying to fix a cosmetic bug in
the printing of error messages: the tests each print
some line without a newline, like:
   fprintf(stdout, "%s addr=%p", __func__, (void *)addr);
and then for the passing case we add a space and complete the line:
   fprintf(stdout, " passed\n");

but this fail_unless() macro is not adding the space, so
presumably we print something awkward like
check_invalid_mmaps addr=0x12435468FAILED at ...

But we should separate out this trivial cleanup from
the patch adding a new test case.

[snip]

Can we leave the printfs for the existing test cases alone?
You can add a new one for your new subcase:
        fprintf(stdout, "%s mremap addr=%p", __func__, addr);

Sorry about all of this---I got quite confused by the printing logic in this file, mainly because AFAICT it's pretty buggy. For instance, the old prints in 'check_invalid_mmaps' would have caused output something like this:

  check_invalid_mmap addr=0x1234check_invalid_mmap addr=0x1234 passed

I agree that this is a separate issue though, so I'll put all of the printing logic back how it was and add a matching fprintf for my new subcase. I'll leave the cleanup here to someone else.

@@ -496,6 +532,7 @@ int main(int argc, char **argv)
         check_file_fixed_eof_mmaps();
         check_file_unfixed_eof_mmaps();
         check_invalid_mmaps();
+    check_shrink_mmaps();

I was going to complain about indent on this line, but the
problem seems to be that the file is incorrectly
indented with hardcoded tabs for parts of it.

Oops! I mostly work in a language where my editor config forces space indentation, so occasionally forget to set space indentation when I do need to. Will correct (and double-check indentation in the rest of the series) in the next revision.

Thanks for the feedback!

--
Matthew

Reply via email to