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