qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] Do not use %m in common code to print error messages


From: Stefano Garzarella
Subject: Re: [PATCH v2] Do not use %m in common code to print error messages
Date: Sat, 19 Oct 2019 16:00:27 +0200
User-agent: NeoMutt/20180716

On Fri, Oct 18, 2019 at 06:01:22PM +0200, Thomas Huth wrote:
> On 18/10/2019 15.49, Kamil Rytarowski wrote:
> > On 18.10.2019 15:42, Stefano Garzarella wrote:
> >> On Fri, Oct 18, 2019 at 03:07:16PM +0200, Thomas Huth wrote:
> >>> The %m format specifier is an extension from glibc - and when compiling
> >>> QEMU for NetBSD, the compiler correctly complains, e.g.:
> >>>
> >>> /home/qemu/qemu-test.ELjfrQ/src/util/main-loop.c: In function 
> >>> 'sigfd_handler':
> >>> /home/qemu/qemu-test.ELjfrQ/src/util/main-loop.c:64:13: warning: %m is 
> >>> only
> >>>  allowed in syslog(3) like functions [-Wformat=]
> >>>              printf("read from sigfd returned %zd: %m\n", len);
> >>>              ^
> >>> Let's use g_strerror() here instead, which is an easy-to-use wrapper
> >>> around the thread-safe strerror_r() function.
> >>>
> >>> While we're at it, also convert the "printf()" in main-loop.c into
> >>> the preferred "error_report()".
> >>>
> >>> Signed-off-by: Thomas Huth <address@hidden>
> >>> ---
> >>>  v2: Do not try to g_free() the strings
> >>>
> >>>  hw/misc/tmp421.c | 4 ++--
> >>>  util/main-loop.c | 3 ++-
> >>>  util/systemd.c   | 4 ++--
> >>>  3 files changed, 6 insertions(+), 5 deletions(-)
> >>
> >> There are many uses of %m also in hw/vfio/ but that's Linux stuff.
> >> Should we change those too or it doesn't matter since it never really
> >> compiled on NetBSD?
> > 
> > It's a gnu (glibc) extension and linux can use alternative libc
> > implementations. Probably most of them capable to host qemu use %m.
> 
> I think I read somewhere that other libcs on Linux also support %m (like

Good to know!

> musl), but I just can't find that reference anymore. Anyway, we can
> still fix that later in case someone hits the issue.
> 

Yes, make sense to me.

Thanks,
Stefano



reply via email to

[Prev in Thread] Current Thread [Next in Thread]