All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 3/4] trace: forbid use of %m in trace event format strings
Date: Fri, 18 Oct 2019 10:34:43 +0100	[thread overview]
Message-ID: <20191018093443.GB28271@redhat.com> (raw)
In-Reply-To: <8e9b4f93-234b-9ae0-0ffc-d96de3ce02cb@redhat.com>

On Fri, Oct 18, 2019 at 11:31:15AM +0200, Thomas Huth wrote:
> On 22/01/2019 19.10, Eric Blake wrote:
> > On 1/22/19 11:23 AM, Daniel P. Berrangé wrote:
> > 
> >>
> >>>> On this point though, does anyone know of any platforms we support[1],
> >>>> or are likely to support in future, where 'strerror' is *not* thread
> >>>> safe ?
> >>>
> >>> I'm not coming up with one, and I think the problem is independent of
> >>> this series (if we DO have a problem, it's a series all its own to
> >>> eradicate the use of strerror() in favor of something safer, either
> >>> picking strerror_l() or dealing with the glibc vs. BSD differences in
> >>> strerror_r()).
> >>
> >> Agree that its not really something for this series - this just
> >> made me think of it again.
> > 
> > Shoot - FreeBSD strerror() is not threadsafe:
> > https://github.com/freebsd/freebsd/blob/master/lib/libc/string/strerror.c#L119
> > 
> > char *
> > strerror(int num)
> > {
> > 	static char ebuf[NL_TEXTMAX];
> > 
> > 	if (strerror_r(num, ebuf, sizeof(ebuf)) != 0)
> > 		errno = EINVAL;
> > 	return (ebuf);
> > }
> > 
> >>
> >> We went through the scrubbing in libvirt to use the sane, but still
> >> tedious to call, variant of strerror_r() many years ago. With luck
> >> though it is a worry that can be confined the dustbin of ancient
> >> UNIX history....unless someone can point to evidence to the contrary ?
> > 
> > libvirt has it easy - they let gnulib do all the work of futzing around
> > with getting a working strerror() despite platform bugs and despite
> > glibc's insistence on a non-POSIX signature if _GNU_SOURCE is defined.
> > We'll have to do a bit more legwork.
> > 
> > That said, I've added it to:
> > https://wiki.qemu.org/Contribute/BiteSizedTasks#Error_checking
> > 
> > if someone wants to do the grunt work.
> 
> I think we should change that task to switch to g_strerror() from glib
> instead ... as far as I can see, this is a proper wrapper around
> strerror_r(), so we don't have to deal with the implementation oddities
> of strerror_r() in QEMU.

Yeah, I think using g_strerror() makes sense. We've just adopted that
in libvirt precisely to avoid these platform portability oddities and
the really unpleasant API calling convention of strerror_r().


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


  reply	other threads:[~2019-10-18  9:36 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18 17:30 [Qemu-devel] [PATCH v2 0/4] trace: make systemtap easier to use for simple logging Daniel P. Berrangé
2019-01-18 17:31 ` [Qemu-devel] [PATCH v2 1/4] display: ensure qxl log_buf is a nul terminated string Daniel P. Berrangé
2019-01-18 17:40   ` Eric Blake
2019-01-18 17:42     ` Daniel P. Berrangé
2019-01-21  7:14   ` Gerd Hoffmann
2019-01-21 10:45   ` Stefan Hajnoczi
2019-01-22 14:17     ` Daniel P. Berrangé
2019-01-18 17:31 ` [Qemu-devel] [PATCH v2 2/4] trace: enforce that every trace-events file has a final newline Daniel P. Berrangé
2019-01-18 17:42   ` Eric Blake
2019-01-22 14:43     ` Daniel P. Berrangé
2019-01-21 10:47   ` Stefan Hajnoczi
2019-01-18 17:31 ` [Qemu-devel] [PATCH v2 3/4] trace: forbid use of %m in trace event format strings Daniel P. Berrangé
2019-01-18 17:50   ` Eric Blake
2019-01-18 22:50     ` Alex Williamson
2019-01-22 14:32     ` Daniel P. Berrangé
2019-01-22 17:19       ` Eric Blake
2019-01-22 17:23         ` Daniel P. Berrangé
2019-01-22 18:10           ` Eric Blake
2019-10-18  9:31             ` Thomas Huth
2019-10-18  9:34               ` Daniel P. Berrangé [this message]
2019-01-18 17:31 ` [Qemu-devel] [PATCH v2 4/4] trace: add ability to do simple printf logging via systemtap Daniel P. Berrangé
2019-01-18 18:14   ` Eric Blake
2019-01-21 10:53     ` Stefan Hajnoczi
2019-01-22 14:34       ` Daniel P. Berrangé
2019-01-22 14:39     ` Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191018093443.GB28271@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.