On Mon, 7 Sep 2020 at 11:24, Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > * Alejandro Colomar via Libc-alpha: > > > pthread_setaffinity_np() and pthread_getaffinity_np(), "on error, > > return a non-zero error number". Usually that kind of library > > functions return -1, and I don't know if this case is different. The > > RETURN VALUE section doesn't specify. Actually the words "error > > number" hint that it is an `errno` value, because it's the same words > > in errno.3, but it could be clearer, and maybe also point to errno(3) > > in that page. > > Most libpthread functions return errno codes instead of in addition to > setting errno. This is something that POSIX requires. The asymmetry is > annoying. I think it dates back to the days where libpthread was purely > a library in some implementations, to be used with a C library that was > not even aware of threads and did not have a per-thread errno variable. > (Of course, that didn't work too well, but people tried.) I had always understood that it was POSIX's attempt to address the design fault inherent in traditional APIs whereby there weresometimes conflicts in the dual purpose of the return value to indicate both success/failure and to return valid information. Thus, for example, the mess with getpriority(2) and one or other APIs where a return value of -1 becomes ambiguous. See also posix_fadvise(), posix_fallocate(), posix_madvise(), which are APIs created by POSIX that do the same thing (though on the other hand, posix_openpt() does not). But, your explanation also sounds plausible, Florian. I wonder which is correct. Cheers, Michael
