Since its introduction in v0.9.1~65 the virOnce() was expected to
follow the usual retval logic (0 for success, a negative number
for failure). However, that was never the case.

On the other hand, looking into glibc and musl the pthread_once()
never returns anything other than zero (uclibc-ng seems to not
implement pthread_once()), therefore we never really hit any
problem. But for code cleanliness (and to match POSIX
documentation), let's change to code so that our retval logic is
honoured.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
 src/util/virthread.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/util/virthread.c b/src/util/virthread.c
index 5ddbf7c49a..e89c1a09fb 100644
--- a/src/util/virthread.c
+++ b/src/util/virthread.c
@@ -39,7 +39,15 @@
 
 int virOnce(virOnceControl *once, virOnceFunc init)
 {
-    return pthread_once(&once->once, init);
+    int ret;
+
+    ret = pthread_once(&once->once, init);
+    if (ret != 0) {
+        errno = ret;
+        return -1;
+    }
+
+    return 0;
 }
 
 
-- 
2.26.3

On a Tuesday in 2021, Michal Privoznik wrote:
>Since its introduction in v0.9.1~65 the virOnce() was expected to
>follow the usual retval logic (0 for success, a negative number
>for failure). However, that was never the case.
>
>On the other hand, looking into glibc and musl the pthread_once()
>never returns anything other than zero (uclibc-ng seems to not
>implement pthread_once()), therefore we never really hit any
>problem. But for code cleanliness (and to match POSIX
>documentation), let's change to code so that our retval logic is
>honoured.
>
>Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
>---
> src/util/virthread.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>

Reviewed-by: Ján Tomko <jtomko@redhat.com>

Jano