Re: Borland C++Builder support

[Will Bryant <will dot bryant at ecosm dot com>]

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 
doesn't.

> 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.