X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
Date: Sat, 01 Jan 2005 12:45:51 +0200
From: "Eli Zaretskii" <eliz AT gnu DOT org>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp-workers AT delorie DOT com
Message-ID: <01c4efef$Blat.v2.2.2$353e15e0@zahav.net.il>
Content-Transfer-Encoding: 7BIT
Content-Type: text/plain; charset=ISO-8859-1
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 2.2.2
In-reply-to: <b24ct0djfmkn9sq8tjr2df792rfhdf4d0e@4ax.com> (message from Brian
	Inglis on Fri, 31 Dec 2004 19:57:23 -0700)
Subject: Re: More complaints from tests/libclink/check
References: <nl8bt0dmp86bl0u788bc1i98l0plk2tipn AT 4ax DOT com>
 <200501010119 DOT j011JVxi015678 AT speedy DOT ludd DOT ltu DOT se> <b24ct0djfmkn9sq8tjr2df792rfhdf4d0e AT 4ax DOT com>
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

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