This fixes issue with would-fail-if-applied-to-thread-right-away
qb_log_thread_priority_set invocation when logging thread doesn't
exist yet, which will arrange for calling itself at the time of
thread's birth that is the moment it will actually fail.
In this + lock-could-not-have-been-initialized corner cases, the
already running thread would proceed as allowed by error condition
handling in the main thread, trying to dereference uninitialized
(or outdated) pointer to the lock at hand, resulting in segfault.
Also include the test that would have been caught that (we use the
fact that it doesn't matter whether setting of the scheduler parameters
fails due to bad input or just because of lack of privileges as it's
the failure at the right moment that is of our interest).
See also:
https://github.com/ClusterLabs/libqb/issues/229
If a tag of 0 is passed into the logger and an existing callsite
is found with a non-zero tag, the don't overwrite the existing tag.
Signed-off-by: Christine Caulfield <ccaulfie@redhat.com>
Unfortunately, the change in test names introduced with commit e990681
hadn't been reflected (until now).
Also reformat shell syntax per more usual convention.
... where appropriate space is measured for, surprisingly, a char,
not for an int. Note that's also the actual type used for both
de-/serializing, so there's no conflict.
Also bother to explain why, now surprisingly for real, an unsigned int
is scraped out from va_list (akin to to STDARG(3)).
Under the influence of libxml2 and considering that actual "patch"
information in fact, if significant, ends up encoded in QB_VER_REST,
shift away from convention codified, e.g., by semver.org (not adored
by libqb, anyway) and rename designated PATCH component of the version
to MICRO accordingly.
Note that at this point, after a release without any header-based
versioning present and just a few commits after it was tentatively
introduced, it's a painless change. Once this PATCH nomenclature
is leaked into a full release, there's no way to get rid of it
reasonably...
Recent "v1.0" discovered this discrepancy propagated all around
and also this is not very compatible with the logic of commit 26d3911.
Treat missing "patch" component of the version as an implicit zero
to make such oddity go away.
Adjust spec file generation accordingly.
Mainly as a light-weight alternative to full-blown autoconf/pkg-config
machineries, whereby one can:
* workaround functionality not present in libqb up to 1.0 (inclusive)
- note that this versioning schema is being introduced *after*
1.0.0 release so one cannot tell that version from any older,
but will be able to safely identify any later one (1.0.1+)
and act accordingly
- example:
#if !defined(QB_VER_MAJOR) || ((QB_VER_MAJOR == 1) && (QB_VER_MINOR < 1))
#warning "Feature X not supported"
int do_foo(int arg) { };
#else
int
do_foo(int arg)
{
/* use feature X of libqb */
}
#endif
* make its program report libqb API version it was built with by
emitting QB_VER_STR symbolic string (see tests/print_ver.c for example)
Also added is a print_ver test program to:
* emit how original unparsed version is parsed to particular components
defined in qbconfig.h (QB_VER_{MAJOR,MINOR,PATCH} symbolic integer
constants and QB_VER_REST symbolic string) when being compiled
* emit mentioned QB_VER_STR symbolic string joining the components
back to a single string, plus the components themselves
Resolves: https://github.com/ClusterLabs/libqb/issues/186
