Re: [PATCH] maintenance: compare output of pthread functions for inequality with 0

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Dec 3, 2022, 00:26 UTC
Message-ID: <Y4qXu5+0jP7+r4yl@tapette.crustytoothpaste.net>
In-Reply-To: <221202.86y1rpe7ma.gmgdl@evledraar.gmail.com>

On 2022-12-02 at 22:46:25, Ævar Arnfjörð Bjarmason wrote:

Show 12 quoted lines

> 
> On Fri, Dec 02 2022, brian m. carlson wrote:
> 
> > Yeah, I think we need to do this.  That's because unlike most other
> > functions, the pthread functions _don't_ set errno, and instead return
> > the error value.  That's why on a typical Unix system, we would have
> > never failed before this patch: because errno values are always
> > positive.
> 
> I was skimming the POSIX docs earlier, which seem to indicate that
> you're not promised anyhting about "errno" being set, just the return
> value.

Technically true.  But POSIX says this:

  The value of errno shall be defined only after a call to a function
  for which it is explicitly stated to be set and until it is changed by
  the next function call or if the application assigns it a value. The
  value of errno should only be examined when it is indicated to be
  valid by a function's return value. Applications shall obtain the
  definition of errno by the inclusion of <errno.h>. No function in this
  volume of POSIX.1-2017 shall set errno to 0. The setting of errno
  after a successful call to a function is unspecified unless the
  description of that function specifies that errno shall not be
  modified.

So literally any function can set it and it is unspecified after a pthread function call (which doesn't explicitly say it's set). For example, sync(2), which has no errors defined, could well set errno, although its value would be unspecified (but it would not be zero unless it already was before the call).

However, we don't care there, because POSIX doesn't allow returning multiple errors (that's not very C), and it won't contain anything useful. I should have said instead that they return errors instead of setting errno to indicate them.

> But at the same time I was reading glibc's pthread implementation, where
> a lot of the time (but not all the time!) you'll also get errno, just as
> an artifact of the library carrying forward an error from an internal
> API which failed while setting errno (e.g. malloc()).

And this is probably part of why POSIX has this policy. I'm sure this same thing is true for pretty much every libc.

> In any case, the best thing to do for our codebase is probably:
> 
> 	if ((errno = pthread_create(...)))
>         	die_errno(...);

I agree that's probably fine to do here. If folks feel setting errno this way is too icky, we can also just call die with strerror. I don't have a strong feeling one way or the other.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA