From owner-freebsd-hackers Tue Oct 17 13:41:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA06877 for hackers-outgoing; Tue, 17 Oct 1995 13:41:18 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA06869 ; Tue, 17 Oct 1995 13:41:09 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA28258; Tue, 17 Oct 1995 13:35:27 -0700 From: Terry Lambert Message-Id: <199510172035.NAA28258@phaeton.artisoft.com> Subject: Re: Locale stuff: call for conclusion. To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Tue, 17 Oct 1995 13:35:27 -0700 (MST) Cc: terry@lambert.org, core@FreeBSD.ORG, hackers@FreeBSD.ORG, phk@critter.tfs.com In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 17, 95 11:07:56 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2714 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > >I think XPG/3 is the right short term approach. I'm still a bit > >fuzzy on XPG/3->XPG/4 transition, since I have yet to see a fully > >localized piece of code to let me factor out all the differences. > > I also not see XPG/4 localize code. I mean that I have seen (done) both XPG/3 and XPG/4 localization, I've just not seen a full catalog, etc, localization using both approaches on otherwise identical code. I have some friends at Unisys that have dealt with localization of legacy code, converting from XPG/3 to XPG/4. I'd just have to hit them up for examples, which would take a lot of my and their time. So I can't diff them and see a clear XPG/3->XPG/4 migration path with only partial jobs (ie: no message catalogs or whatever). > I plan to made XPG/3 library from our XPG/4 sources, and this work > almost done indirectly when wrote my hack. > > I can ether > 1) disable rune coding expect NONE in mklocale and tune setlocale > to not load rune coding. I'd prefer a default disabling of runic encoding usage. I expect that eventually this would later go away as the code is updated, so it becomes a code migration issue. > It is very fast solution but unused runes code still bloats > stati binaries. As long as it is transitional code with a deadline for removal, it's fine to include it. Maybe even use a preprocessor test to start spitting messages in transitional code if compiled after some date. (I know: it's evil). > or 2) Ifdef all XPG4 code (by #ifdef XPG4 f.e.) additionly to 1). > or 3) Remove all XPG4-related sources and left only XPG3-related files > additionly to 1) Better to #ifdef. I assume that one day we will want to support XPG/4, and it would be better to not have to recreate the code from scratch to do so. It also gives a quick testbed that will let us understand the code migration issues. Typically, I'd like a library to be linked before libc that let me have XPG/4 instead of XPG/3 so I could migrate the now XPG/3 code to XPG/4 awareness without having to do it all at once. That also means a function reference kludge for symbol preresoloution using XPG/4 symbol definitions before the symbols are required by the rest of the libc code. Probably a required dead code stub that lives in the same object module as setlocale() and pulls in everything else, which can also be removed when/if XPG/4 replaces XPG/3 in libc. I get a bit wary when you have to start playing linker tricks, but in this case, it seems the best approach for getting a code transitioning platform up and running with the least effort. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.