X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f Date: Fri, 07 Jan 2005 17:09:21 -0700 From: Brian Inglis Subject: Re: setlocal... In-reply-to: <200501072339.j07NdSrl026313@speedy.ludd.ltu.se> To: DJGPP-workers Cc: ams AT ludd DOT ltu DOT se 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: <200501072339 DOT j07NdSrl026313 AT speedy DOT ludd DOT ltu DOT se> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id j080JPIe014498 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, 08 Jan 2005 00:39:28 +0100 (CET), ams AT ludd DOT ltu DOT se wrote: >According to Brian Inglis: >> Appended the changes to setlocal and its version of strftime which will >> then be identical to the updated version of libc strftime which I changed. >> As these are not under CVS control, I generated diffs between the DJGPP >> contrib/liblocal.02 directory and my development directory then edited >> the new file path to match the old file path, and hope this works okay. > >Yes. And I think I've been over those without finding anything. Note: >I want the patch to src/libc/ansi/locale/setlocal.txh. Given that >neither you or me can find one, perhaps there isn't one. What do I >know? Perhaps a completely rewrite of setlocale() won't need and >documentation update? (I surely did think it would. Suprise!) Alexander Aganichev includes an updated setlocal.txh in his distribution under: contrib/liblocal.02/src/ansi/locale/setlocal.txh. I'll append a diff against cvs/djgpp/src/libc/ansi/locale/setlocal.txh. >> >The changes to strftime.c and friends are dependand of the setlocale >> >patch, right? >> >> AIUI the only interface is the __dj_date_format and __dj_time_format >> global variables which are defaulted in strftime but can be set by >> calling setlocale(). >> >> Some of the time test programs call setlocale() and change the TZ >> env var to check out handling these variations. > >Ok. So you mean I should be able to commit the strftime.c and friends >changes without any bad side effects, except the test programs might >not give the right answers until setlocale() is updated? Those tests that change the timezone or locale will not be correct if their respective packages are not installed. >> >I want to apply your setlocal patch because my cvs copy has so many >> >changes that I'm having problems knowing what is what. But to do that >> >I want to have the documentation up-to-date too. >> > >> >Are you planning to recode setlocal.c so it uses other functions >> >instead of stpcpy() and itoa()? If you are, it's counterproductive to >> >add those as stubs as they'll disappear again rather quickly; or not >> >which can be the real problem. >> >> On Thu, 30 Dec 2004 09:24:08 +0300 (MSK), in Re: setlocale patch, >> Alexander Aganichev said he would review my fixes and incorporate >> them, and deal with those other issues. >> >> If the updated version of strftime is incorporated into libc, >> then he can eliminate the version he provided with liblocal.02, >> which the appended patch makes identical. > >Yes. But either I'm missing something or you didn't answer my question. >Your fixes didn't affect the status regarding stpcpy() and itoa() >because I used your (what I think is more recent) corrected source. > >As I see it, the version from you is more up-to-date than what we got >from Alexander Aganichev (because your's is newer). And that one pulls >in the non-ansi functions stpcpy() and itoa(). They don't appear in my patch, so they must be in the original sources. >> >That change itself is in no great hurry. Actually I'd prefer if that >> >change came later as I had to make some minor adjustment to the code I >> >got from you to make it compile and I really want to commit that new >> >setlocal.c after which you can submit a small patch. >> >> If he doesn't have time, I can deal with them right now. > >Deal away. I've not been in contact with Alexander Aganichev >specifically, as I'm now with you (because it's you that is most >active and I chose to email you). If you think I really should talk >directly with Alexander Aganichev I could do so. > >However as I stated (or tried to anyway), I'd prefer to commit what I >got with regards to setlocal.c and what I suspect is wandering the net >with regards to setlocal.txh (which I can't find), so I can get a >little more sane cvs tree. And then we take care of stpcpy() and >itoa(). _If_ we are aiming to take care of stpcpy() and itoa() at >all. I'll do that, and if Alexander Aganichev wants to incorporate that into a new release, or handle it better, great. >> I'll pull my patch summaries and edit those into new patches to wc204. >> The setlocale() patch contains only minor bug fixes for resetting >> the locale and returning the correct name. > >Please do. > >> --- contrib/liblocal.02/src/ansi/locale/setlocal.c 2002-07-17 02:16:36.000000000 -0600 >> +++ contrib/liblocal.02/src/ansi/locale/setlocal.c 2004-02-24 01:57:18.000000000 -0700 > >setlocal.c > >> --- contrib/liblocal.02/src/ansi/time/strftime.c 2002-06-08 04:18:06.000000000 -0600 >> +++ contrib/liblocal.02/src/ansi/time/strftime.c 2004-02-29 00:04:48.000000000 -0700 > >strftime.c > > >No sign of a setlocal.txh patch. No need, no functional change, just a bug fix. Thanks. Take care, Brian Inglis Note that the first section of this diff should probably be deleted before applying it as a patch to the previous libc version. --- cvs/djgpp/src/libc/ansi/locale/setlocal.txh 2003-01-29 22:08:38.000000000 -0700 +++ contrib/liblocal.02/src/ansi/locale/setlocal.txh 2002-06-08 09:34:56.000000000 -0600 @@ -1,6 +1,5 @@ @c ---------------------------------------------------------------------- @node setlocale, locale -@findex setlocale @subheading Syntax @example @@ -42,10 +41,12 @@ @end table -The @var{locale} should be the name of the current locale. Currently, -only the "C" and "POSIX" locales are supported. If the @var{locale} -is NULL, no action is performed. If @var{locale} is "", the locale is -identified by environment variables (currently not supported). +The @var{locale} should be the name of the current locale. Supported +locales includes user default locale (in this case settings obtained from +the @var{country.sys} driver) and standard "C" and "POSIX" locales. You +may address to user default locale by it's name if you want. If the +@var{locale} is NULL, no action is performed. If @var{locale} is "", the +locale is identified by environment variables. @xref{localeconv}.