Date: Thu, 17 Jul 2014 14:21:10 -0700 From: Garrett Cooper <yaneurabeya@gmail.com> To: Garrett Wollman <wollman@csail.mit.edu> Cc: bugzilla-noreply@FreeBSD.org, freebsd-standards@freebsd.org Subject: Re: [Bug 191906] New: pthread_cancel(NULL) on FreeBSD returns EINVAL, not ESRCH according to manpage Message-ID: <CAGHfRMBYZ9m6FL5MBCPtUYUwo6O4hbWzO49MWas1zRpMiWCvtg@mail.gmail.com> In-Reply-To: <21448.10927.483892.974746@khavrinen.csail.mit.edu> References: <bug-191906-15@https.bugs.freebsd.org/bugzilla/> <21448.10927.483892.974746@khavrinen.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 17, 2014 at 12:57 PM, Garrett Wollman <wollman@csail.mit.edu> wrote:
> <<On Thu, 17 Jul 2014 03:13:01 +0000, bugzilla-noreply@freebsd.org said:
>
>> According to pthread_cancel(3) and opengroup, pthread_cancel should
>> only return ESRCH, not EINVAL (but it apparently returns EINVAL for
>> thread=NULL).
>
> According to my copy of SUSv7 (1003.1-2008):
>
> RETURN VALUE
> If successful, the pthread_cancel ( ) function shall return zero; otherwise, an error number shall be
> returned to indicate the error.
> ERRORS
> The pthread_cancel ( ) function shall not return an error code of [EINTR].
>
> That is the entirety of what it says about errors for
> pthread_cancel(). (Page 1572 in the SUSv7 PDF for those following at
> home.)
>
> SUSv6 (1003.1-2001) said something different:
>
> ERRORS
> The pthread_cancel ( ) function may fail if:
> [ESRCH] No thread could be found corresponding to that specified by the given thread
> ID.
> The pthread_cancel ( ) function shall not return an error code of [EINTR].
>
> This error was removed, and passing an invalid pthread_t value to
> pthread_cancel() is now UNDEFINED in SUSv7. This was changed because
> pthread_t is a pointer in some branded Unix systems (as well as
> FreeBSD), and SUSv6 mistakenly required pthread_t to be an arithmetic
> type. It was felt that these implementations should not be required
> to validate pthread_t values -- they should be entitled to rely on C's
> usual lack-of-semantics for invalid pointers. (Recall that in C,
> merely *loading* an invalid pointer causes undefined behavior, so you
> clearly are already in UB territory if you try to pass one to a
> function.)
>
> The test you cite is simply wrong, albeit for the opposite reason:
>
> int
> main(void)
> {
> int rv = pthread_cancel(NULL);
>
> printf("%s\n", strerror(rv));
> return (0);
> }
>
> There is no guarantee that NULL can be converted to pthread_t, and
> applications are not allowed to "look inside" the typedef and use the
> special properties of the underlying type.
Good point (I vaguely remember that discussion on the Austin Group
list). This test should be removed in FreeBSD / NetBSD.
Thanks!
-Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGHfRMBYZ9m6FL5MBCPtUYUwo6O4hbWzO49MWas1zRpMiWCvtg>