X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f Date: Sat, 01 Jan 2005 09:27:08 -0700 From: Brian Inglis Subject: Re: More complaints from tests/libclink/check In-reply-to: <01c4efef$Blat.v2.2.2$353e15e0@zahav.net.il> To: djgpp-workers AT delorie DOT com Message-id: Organization: Systematic Software MIME-version: 1.0 X-Mailer: Forte Agent 1.93/32.576 English (American) Content-type: text/plain; charset=us-ascii References: <200501010119 DOT j011JVxi015678 AT speedy DOT ludd DOT ltu DOT se> <01c4efef$Blat.v2.2.2$353e15e0 AT zahav DOT net DOT il> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id j01GRATv011937 Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sat, 01 Jan 2005 12:45:51 +0200, Eli Zaretskii wrote: >> Date: Fri, 31 Dec 2004 19:57:23 -0700 >> From: Brian Inglis >> >> On Sat, 01 Jan 2005 02:19:31 +0100 (CET), ams AT ludd DOT ltu DOT se wrote: >> >> >According to Brian Inglis: >> >> On Fri, 31 Dec 2004 13:42:52 +0100 (CET), ams AT ludd DOT ltu DOT se wrote: >> >... >> >> >Missing POSIX functions: >> >> >asctime_r >> >> >ctime_r >> >> >gmtime_r >> >> >localtime_r >> >> >strptime >> >> >> >> I can supply those as part of my changes to time functions. >> > >> >Let's hear it! (Post the patches, i.e.) >> >> How do we want to handle these? >> The ISO functions become wrappers which define static storage and call >> the POSIX *_r functions. >> Do we want to define the POSIX functions as _*_r and then use the >> _/environ approach to define them when referenced, have the POSIX >> headers #define *_r as _*_r, or have POSIX functions *_r call _*_r? > >Some design decision is in order, IMHO. > >The *_r functions are supposed to be reentrant versions of the >respective non-*_r functions, right? So what reentrancy are we >willing to have? Do we want functions that are thread-safe wrt some >threading package ported to DJGPP? Or do we claim that, since DJGPP >doesn't support multithreading as part of the basic package, the *_r >functions can simply be aliases for non-*_r functions? The *_r _POSIX_THREAD_SAFE_FUNCTIONS have different interfaces that support reentrancy/threads by allowing the caller to pass a buffer/struct pointer instead of using/returning an internal static buffer/struct. Allocation of any other buffer/struct storage required as auto/dynamic should be sufficient to meet the reentrancy requirement. I don't think we need to worry explicitly about threads within these functions. -- Thanks. Take care, Brian Inglis