Re: [PATCH 04/18] tests: print newline after QMP response in qtest logs

[Thomas Huth]

On 10/03/2022 12.35, Daniel P. Berrangé wrote:
> On Thu, Mar 10, 2022 at 03:11:08PM +0400, Marc-André Lureau wrote:
> > Hi
> >
> > On Thu, Mar 10, 2022 at 2:56 PM Daniel P. Berrangé <berrange@redhat.com>
> > wrote:
> >
> > > On Mon, Mar 07, 2022 at 11:09:37AM +0100, Thomas Huth wrote:
> > > > On 07/03/2022 11.06, Daniel P. Berrangé wrote:
> > > > > On Mon, Mar 07, 2022 at 02:51:23PM +0800, Peter Xu wrote:
> > > > > > On Wed, Mar 02, 2022 at 05:49:18PM +0000, Daniel P. Berrangé wrote:
> > > > > > > The QMP commands have a trailing newline, but the response does
> > > not.
> > > > > > > This makes the qtest logs hard to follow as the next QMP command
> > > > > > > appears in the same line as the previous QMP response.
> > > > > > >
> > > > > > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > > > > > > ---
> > > > > > >    tests/qtest/libqtest.c | 3 +++
> > > > > > >    1 file changed, 3 insertions(+)
> > > > > > >
> > > > > > > diff --git a/tests/qtest/libqtest.c b/tests/qtest/libqtest.c
> > > > > > > index a85f8a6d05..79c3edcf4b 100644
> > > > > > > --- a/tests/qtest/libqtest.c
> > > > > > > +++ b/tests/qtest/libqtest.c
> > > > > > > @@ -629,6 +629,9 @@ QDict *qmp_fd_receive(int fd)
> > > > > > >            }
> > > > > > >            json_message_parser_feed(&qmp.parser, &c, 1);
> > > > > > >        }
> > > > > > > +    if (log) {
> > > > > > > +        g_assert(write(2, "\n", 1) == 1);
> > > > > > > +    }
> > > > > >
> > > > > > Drop the g_assert() to remove side effect of G_DISABLE_ASSERT?
> > > > >
> > > > > You need to check the return value of write() otherwise you'll get a
> > > > > compile failure due to a warn_unused_result attribute annotation.
> > > > >
> > > > > I don't think G_DISABLE_ASSERT is a problem as we're not defining
> > > > > that in our code.
> > > >
> > > > You could use g_assert_true() - that's not affected by G_DISABLE_ASSERT.
> > >
> > > I don't think we need to do that, per existing common practice:
> > >
> > > $ git grep '\bg_assert('  | wc -l
> > > 2912
> > >
> > > $ git grep '\bg_assert(' tests | wc -l
> > > 2296

I said, you *could* do that, not that you *must* do that ;-)

Since we require compiling without G_DISABLE_ASSERT in the QEMU code base, 
it doesn't really matter for us. But if you're involved in other projects, 
too, where GI_DISABLE_ASSERT might be allowed, it might be good habit to do 
it "right", i.e. use g_assert_true() in case the expression has side effects 
and must never be disabled.

> > >
> > On the topic of assert() usage, it would be nice to state clearly when to
> > assert() or g_assert().
> >
> > g_assert() behaviour is claimed to be more consistent than assert() across
> > platforms.
> >
> > Also -DNDEBUG is less obvious than -DG_DISABLE_CHECKS or -DG_DISABLE_ASSERT.
>
> Personally I would make QEMU build error if NDEBUG or G_DISABLE_ASSERT
> was defined, as running with asserts disabled will lead to unsafe code.
> We rely on asserts firing to avoid compromise of QEMU when faced with
> malicious data.

We already do that, see osdep.h:

#ifdef NDEBUG
#error building with NDEBUG is not supported
#endif
#ifdef G_DISABLE_ASSERT
#error building with G_DISABLE_ASSERT is not supported
#endif


> > I would remove assert.h and prevent from using it back, but I might be
> > missing some reasons to still use it.

I guess it's just grown historically.

First step would be to add an entry to our coding styles, I think.

Then, if we don't care about the code churn, this would be a nice 
BiteSizeTask for new contributors, I think (GSoC etc.), so we could create 
some tickets in the Gitlab issue tracker for this (e.g. split up by subsystem).

 Thomas