Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000599 [1003.1(2008)/Issue 7] System Interfaces Comment Enhancement Request 2012-08-08 22:39 2020-03-20 10:04
Reporter mdempsky View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Matthew Dempsky
Organization OpenBSD
User Reference
Section pthread.h, pthread_equal
Page Number N/A
Line Number N/A
Interp Status ---
Final Accepted Text Note: 0001334
Summary 0000599: Reserved "no thread" value for pthread_t
Description Some software currently non-portably assumes pthread_t is an int or pointer type and also that they can use "0" to represent an illegal thread value (similar to how -1 is used for an illegal file descriptor value). E.g., from the Chromium code base:

  #elif defined(OS_POSIX)
  typedef pthread_t PlatformThreadHandle;
  const PlatformThreadHandle kNullThreadHandle = 0;
  typedef pid_t PlatformThreadId;
  #endif

It would be convenient if POSIX were to add a macro or function that could return a pthread_t value that was guaranteed to compare unequal by pthread_equal() to any valid thread ID.
Desired Action Change <pthread.h> to define a constant expression PTHREAD_NULL of type pthread_t.

Change pthread_equal() to return true if t1 and t2 are the same thread ID or are both PTHREAD_NULL; it's behavior is undefined if either t1 or t2 are neither a valid thread ID or PTHREAD_NULL.


(My intent here is to allow PTHREAD_NULL to be defined simply as "#define PTHREAD_NULL NULL" on systems where pthread_t is a pointer type, but to allow something like "extern const pthread_t PTHREAD_NULL;" on systems where pthread_t is a struct.)
Tags issue8
Attached Files

- Relationships

-  Notes
(0001323)
wlerch (reporter)
2012-08-09 14:25

The proposed text will need to be tightened up a little.

Pedantically speaking, "extern const pthread_t PTHREAD_NULL;" does not make PTHREAD_NULL a constant expression -- just because an expression has a const-qualified type doesn't make it a constant expression in C.

Also, "#define PTHREAD_NULL NULL" doesn't make PTHREAD_NULL an expression of type pthread_t. The type of NULL is either void* or an integer in C.
(0001324)
mdempsky (reporter)
2012-08-10 18:12

Good point. So conforming definitions would have to be something like (just examples):

#define PTHREAD_NULL ((pthread_t)NULL) // pointer type
#define PTHREAD_NULL ((pthread_t)-42) // int type
#define PTHREAD_NULL ((pthread_t){ .foo = -1 }) // struct type

to ensure proper types and that they can be used in all const expression contexts.
(0001325)
mdempsky (reporter)
2012-08-10 18:23

Oh, correction, it would need to be

#define PTHREAD_NULL ((const pthread_t){ .foo = -1 })

for the struct-typed pthread_t to allow it in static initialization contexts.
(0001326)
eblake (manager)
2012-08-15 16:28

Does '(locale_t)0' deserve similar treatment?
(0001328)
mdempsky (reporter)
2012-08-16 15:15

IMO, I don't think (locale_t)0 *needs* such a treatment because (locale_t)0 is already reserved as a distinct value separate from anything duplocale() or newlocale() might return. Adding a define might still be nice though for consistency or for allowing future standards revisions to allow locale_t to be a struct type.
(0001329)
geoffclare (manager)
2012-08-16 16:09

The equivalent for locale_t would not have the value 0, since that already
has a special meaning. It would be a value that is guaranteed not to
compare equal to any valid locale handle (including LC_GLOBAL_LOCALE) nor
to (locale_t)0. A suitable name might be LC_INVALID_LOCALE.
(0001334)
msbrown (manager)
2012-08-29 15:58
edited on: 2012-08-29 16:01

After line 10403 on page 311 of Issue 7 append:
The <pthread.h> header shall define the following compile-time constant expression, valid as an initializer for pthread_t, representing a value that shall not compare equal to the thread ID of any existing thread:

PTHREAD_NULL

On page 314 line 10548 replace "None." with:

Since pthread_t is an opaque type, a definition of PTHREAD_NULL was added to allow for a null value of that type. Some conforming definitions of PTHREAD_NULL could be:

For a pointer type:
#define PTHREAD_NULL ((pthread_t)NULL)
For an integer type:
#define PTHREAD_NULL ((pthread_t)-42)
For a struct type:
#define PTHREAD_NULL ((const pthread_t){ .foo = -1 })


On line 51624 on page 1606 of Issue 7 replace:

If either t1 or t2 are not valid thread IDs, the behavior is undefined.

with

If either t1 or t2 is not a valid thread ID and is not equal to PTHREAD_NULL, the behavior is undefined.

(0004799)
geoffclare (manager)
2020-03-20 10:04

When applying this bug I changed foo to __foo as suggested by Rich Felker on the mailing list on 2020-02-26. In my view this is a minor editorial matter that did not warrant reopening the bug.

- Issue History
Date Modified Username Field Change
2012-08-08 22:39 mdempsky New Issue
2012-08-08 22:39 mdempsky Status New => Under Review
2012-08-08 22:39 mdempsky Assigned To => ajosey
2012-08-08 22:39 mdempsky Name => Matthew Dempsky
2012-08-08 22:39 mdempsky Organization => OpenBSD
2012-08-08 22:39 mdempsky Section => pthread.h, pthread_equal
2012-08-08 22:39 mdempsky Page Number => N/A
2012-08-08 22:39 mdempsky Line Number => N/A
2012-08-09 14:25 wlerch Note Added: 0001323
2012-08-10 18:12 mdempsky Note Added: 0001324
2012-08-10 18:23 mdempsky Note Added: 0001325
2012-08-15 16:28 eblake Note Added: 0001326
2012-08-16 15:15 mdempsky Note Added: 0001328
2012-08-16 16:09 geoffclare Note Added: 0001329
2012-08-29 15:58 msbrown Note Added: 0001334
2012-08-29 15:59 msbrown Tag Attached: issue8
2012-08-29 16:01 msbrown Note Edited: 0001334
2012-08-29 16:03 msbrown Interp Status => ---
2012-08-29 16:03 msbrown Final Accepted Text => Note: 0001334
2012-08-29 16:03 msbrown Status Under Review => Resolved
2012-08-29 16:03 msbrown Resolution Open => Accepted As Marked
2020-03-20 10:04 geoffclare Note Added: 0004799
2020-03-20 10:04 geoffclare Status Resolved => Applied


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker