Thomas Huth <th...@redhat.com> wrote: > On 23/03/2023 19.31, Juan Quintela wrote: >> Daniel P. Berrangé <berra...@redhat.com> wrote: >>> The TAP protocol version line must be the first thing printed on >>> stdout. The migration test failed that requirement in certain >>> scenarios: >>> >>> # Skipping test: Userfault not available (builtdtime) >>> TAP version 13 >>> # random seed: R02Sc120c807f11053eb90bfea845ba1e368 >>> 1..32 >>> # Start of x86_64 tests >>> # Start of migration tests >>> .... >>> >>> The TAP version is printed by g_test_init(), so we need to make >>> sure that any methods which print are run after that. >>> >>> Signed-off-by: Daniel P. Berrangé <berra...@redhat.com> >>> --- >> Reviewed-by: Juan Quintela <quint...@redhat.com> >> >>> - const bool has_kvm = qtest_has_accel("kvm"); >>> - const bool has_uffd = ufd_version_check(); >>> - const char *arch = qtest_get_arch(); >>> + bool has_kvm; >>> + bool has_uffd; >>> + const char *arch; >> Why don't you move also the declarations of the variables? >> I think that one of the biggest troubles of C is variables that are not >> initialized. >> All compilers that we support are C99 or later, so we can do that >> (and >> we already do in lot of places.) > > I think the coding style has been created before we switched to > -std=gnu99 for compiling QEMU, so a lot of GCCs were still using C89 > by default?
Yes, that is the actitude. I got sick when I see new code that still does: char *foo = (char *)malloc(...); It is is C89, it has been enough to know that it is not needed. And yes, that particular one is not used in qemu anymore, but: void *opaque; .... Foo *foo = (Foo *)opaque; Is still introduced in new code, and it is not needed since C89. >> And yeap, I know that CodingStyle says otherwise, but I think that what >> is wrong is CodingStyle. >> https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg03836.html > > Please use proper prefixes in the subject when sending patches > ("docs/devel:" here), otherwise your patches might not get the right > attention (at least on my side, it was filtered away as a patch that > was relevant to me) - and also put some recent contributors on CC: I didn't knew the docs/devel preffix. About the CC'd, I expected that git-publish be good enough at doing that, but it appears not. Anyways, thanks. Later, Juan.