Date: Tue, 17 Oct 1995 13:35:27 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Cc: terry@lambert.org, core@FreeBSD.ORG, hackers@FreeBSD.ORG, phk@critter.tfs.com Subject: Re: Locale stuff: call for conclusion. Message-ID: <199510172035.NAA28258@phaeton.artisoft.com> In-Reply-To: <kmSq0XmWr7@ache.dialup.demos.ru> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 17, 95 11:07:56 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510172035.NAA28258>