git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Rose via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Seija <doremylover123@gmail.com>
Subject: Re: [PATCH] maintenance: compare output of pthread functions for inequality with 0
Date: Sat, 3 Dec 2022 00:26:35 +0000	[thread overview]
Message-ID: <Y4qXu5+0jP7+r4yl@tapette.crustytoothpaste.net> (raw)
In-Reply-To: <221202.86y1rpe7ma.gmgdl@evledraar.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2636 bytes --]

On 2022-12-02 at 22:46:25, Ævar Arnfjörð Bjarmason wrote:
> 
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

      reply	other threads:[~2022-12-03  0:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-02 17:02 [PATCH] maintenance: compare output of pthread functions for inequality with 0 Rose via GitGitGadget
2022-12-02 18:05 ` Jeff Hostetler
2022-12-02 18:10 ` Ævar Arnfjörð Bjarmason
2022-12-02 18:44   ` Jeff Hostetler
2022-12-02 20:55   ` brian m. carlson
2022-12-02 22:46     ` Ævar Arnfjörð Bjarmason
2022-12-03  0:26       ` brian m. carlson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y4qXu5+0jP7+r4yl@tapette.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=avarab@gmail.com \
    --cc=doremylover123@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).