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 <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
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:	<s6jdt0di1q4p006d6ucf7fd10i5isiqb7o@4ax.com>
Organization:	Systematic Software
MIME-version:	1.0
X-Mailer:	Forte Agent 1.93/32.576 English (American)
References:	<nl8bt0dmp86bl0u788bc1i98l0plk2tipn AT 4ax DOT com>
	<200501010119 DOT j011JVxi015678 AT speedy DOT ludd DOT ltu DOT se>
	<b24ct0djfmkn9sq8tjr2df792rfhdf4d0e AT 4ax DOT com>
	<01c4efef$Blat.v2.2.2$353e15e0 AT zahav DOT net DOT il>
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

On Sat, 01 Jan 2005 12:45:51 +0200, Eli Zaretskii <eliz AT gnu DOT org>
wrote:

>> Date: Fri, 31 Dec 2004 19:57:23 -0700
>> From: Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
>> 
>> 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

- Raw text -