This is the mail archive of the mailing list for the pthreas-win32 project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]