From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 691 invoked by alias); 7 Aug 2004 02:52:52 -0000 Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sources.redhat.com Received: (qmail 646 invoked from network); 7 Aug 2004 02:52:51 -0000 Received: from unknown (HELO serge.ecosm.com) (202.37.218.3) by sourceware.org with SMTP; 7 Aug 2004 02:52:51 -0000 Received: (qmail 21349 invoked by uid 503); 7 Aug 2004 02:52:49 -0000 Received: from 203-79-66-6.adsl-wns.paradise.net.nz (HELO ?192.168.2.20?) (203.79.66.6) by serge.ecosm.com with SMTP; 7 Aug 2004 02:52:49 -0000 Message-ID: <41144407.4000702@ecosm.com> Date: Sat, 07 Aug 2004 02:52:00 -0000 From: Will Bryant Organization: eCOSM Limited User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) MIME-Version: 1.0 To: pthreads-win32@sources.redhat.com Subject: Re: Borland C++Builder support References: <200408031004.i73A4qlB013157@www2.pochta.ru> <41138855.1010605@ecosm.com> <4113B7D2.7090807@ise.canberra.edu.au> In-Reply-To: <4113B7D2.7090807@ise.canberra.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg00098.txt.bz2 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.