[Libguestfs] [libnbd PATCH] copy: Fail nbdcopy if NBD read or write fails
Eric Blake
eblake at redhat.com
Fri Feb 4 13:13:23 UTC 2022
On Fri, Feb 04, 2022 at 09:31:19AM +0100, Laszlo Ersek wrote:
> On 02/03/22 15:12, Eric Blake wrote:
> > On Thu, Feb 03, 2022 at 02:46:27PM +0200, Nir Soffer wrote:
>
> >> So we would use fprintf and strerror, and setting errno would be needed
> >> although it can be used with %m (is it portable?).
> >
> > %m is not portable in *printf(3). It IS portable in syslog(3), which
> > is why glibc printf(3) supports %m as well; and in nbdkit, we use a
> > printf wrapper on non-glibc to give unconditional %m support to nbdkit
> > plugins. But we do not have that printf wrapper here. Using
> > strerror() instead of perror() is doable in applications (we shouldn't
> > do it directly in libnbd since strerror() has multi-threaded
> > implications and we don't control what the application may be doing in
> > other threads, but in nbdcopy we control the entire application).
>
> Side topic: what do we think about strerror_r()?
The glibc and POSIX signatures differ, making it a pain to use
portably. Gnulib has LGPLv2+ wrappers that work around that, but we
can't use gnulib in nbdkit, and libnbd has (so far) been able to cope
without needing a dependency on gnulib.
I also seem to recall that we haven't audited nbdkit for unsafe uses
of strerror and strerror_r, partly because it is relatively
unrewarding grunt work.
>
> ... Hmmm I recall something... Yep: we now have guestfs_int_strerror()
> in the libguestfs-common project at least.
>
> (We cannot just copy it over I think, due to licence differences;
> however, with Rich having authored commit 9ec7cd8e23b5 ("utils: Fix
> usage of strerror_r", 2021-12-09), Red Hat seems to "own the copyright
> on that function" (if this statement makes any sense), so we could
> "relicense" it.)
Yes, that is an option, if we decide that it is time to perform that
audit (but it is not my highest priority at the moment).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
More information about the Libguestfs
mailing list