delorie.com/archives/browse.cgi | search |
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> |
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 |
> 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?
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |