This is the mail archive of the
mailing list for the pthreas-win32 project.
Re: Borland C++Builder support
Ross Johnson wrote:
There are pthreads implementations that allow a NULL thread parameter
(Solaris - see below) and the question of a NULL value has been asked
before on this list. My copy of the SUSV3 standard doesn't say that
NULL can't be passed and doesn't require an error be returned. It
appears to be left to the implementation.
My Linux man page says "On success, the identifier of the newly created
thread is stored in the location pointed by the _thread_ argument, and a
0 is returned.", and my Solaris man page says "Upon successful
completion, pthread_create() stores the ID of the created thread in the
location referenced by _thread_.", so strictly speaking since neither
says "if _thread_ is non-NULL" one should _expect_ that it would
segfault, though only a true pedant would claim that it's a bug if it
In pthreads-win32, a memory protection fault is raised if NULL is
passed, but it also starts the thread before the fault is raised,
which is probably a bug.
I agree, it should do one or the other.
Pthreads-win32 could probably emulate Solaris with a one line change.
The question is:- which behaviour is preferrable?
Good question. Presumably anyone who's using pthreads-win32 is using it
to acheive cross-platform portability. I was initially going to put in
my vote for cleanly handling this as an error condition, on the basis
that that way people can expect their pthreads-win32 programs to run on
Linux. But, having thought about it a bit more, I think it's more
likely that people using pthreads-win32 will be porting solaris
applications to win32 than writing win32 apps with pthreads and then
porting them to Linux.
So my vote is to go with the Solaris behaviour and accept NULL arguments.
But I would like it to be documented somewhere that this behaviour is
not required. Either behaviour seems acceptable to me, just not the
current half-works, half-doesn't behaviour.