Juan Quintela <quint...@redhat.com> writes:
> 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. I've just sent: Subject: [RFC PATCH] MAINTAINERS: add a section for policy documents Date: Fri, 24 Mar 2023 17:38:36 +0000 Message-Id: <20230324173836.1821275-1-alex.ben...@linaro.org> to collect willing victims^H^H^H^H^H^H volunteers who want to track project related discussions like this. > > Anyways, thanks. > > Later, Juan. -- Alex Bennée Virtualisation Tech Lead @ Linaro