Mail Archives: djgpp-workers/2005/01/07/19:19:51
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}.
- Raw text -