search for: ef4f72ef

...ce I'll wait for review before pushing. Not fixed here, but still worth doing: Audit and fix all our uses of nbdkit_error("...\n") to drop their trailing newline, as nbdkit_error() adds one. Then update nbdkit_error() to actually do smart newline appending (borrowing from commit ef4f72ef) so that other callers outside our codebase get smart handling by default. And on a tangent, I just filed a gcc bug about not flagging %m during some form of -Wformat: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88270 -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-3...

...re pushing. > > Not fixed here, but still worth doing: > > Audit and fix all our uses of nbdkit_error("...\n") to drop their > trailing newline, as nbdkit_error() adds one.  Then update > nbdkit_error() to actually do smart newline appending (borrowing from > commit ef4f72ef) so that other callers outside our codebase get smart > handling by default. Also not fixed: strerror() is not threadsafe (at all) on FreeBSD. On glibc, it is at least thread-safe for safe input values (that is, if passed 0 or a value from <errno.h>, the resulting string has lifetime in c...

Our use of "%m" in various error messages is testament to the project's initial life on Linux - but other than Cygwin, I know of no other platforms supporting that glibc extension. We COULD audit the code and manually turn "%m" into "%s"/strerror(errno), but that's a lot of churn. Instead, let's fix the few outliers that can't be easily wrapped, then