Date: Wed, 18 Oct 1995 13:46:37 -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, kaleb@x.org, phk@critter.tfs.com, wollman@lcs.mit.edu Subject: Re: Locale stuff: call for conclusion. Message-ID: <199510182046.NAA00860@phaeton.artisoft.com> In-Reply-To: <ymSB8XmWF0@ache.dialup.demos.ru> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 18, 95 07:30:20 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Leave all 8-bit unclean code unlocalized. > > Alternative: cleanup 8bit unclean code. Garrett's alternative: cleaunup non-XPG/4 localized code. They sound equally valid when you say them this way, don't they? The problem with making an arbitrary cutoff that prevents gradual migration in one case (XPG/3->XPG/4) but not another (8-bit->XPG/3) is that it is arbitrary where you put the line. Garret's placement and your placement of that line can't be judged to be better or worse than each other, because both are equally arbitrary. You wish to compromise gradual migration of 7->8-bit because there is very little work to go from 8-bit->base-level-XPG/3, and because it benefits you personally to make the requirement that code be 8-bit clean. Garrett's intended requirement that code be XPG/4 localized or that it not call setlocale() destroys gradual migration from any code to XPG/4 localization, but benefits all users of the code (eventually). Garrett's proposal, which would be hard on the existing users of the ctr0.o hack (the poor man's XPG/3), would result in an all-or-nothing choice. But it has a high degree of intellectual honesty. My proposal would allow 7bit code to act unlocalized, and potentially broken when using the locale-specific features of ctype.h and/or when operating on 8bit data (little change from the status quo, since the use of the ctype functions instead of code-based tests is a partial attempt at 8-bit cleanliness). It would allow 8-bit clean code to be loaclized using XPG/3, which would exclude rune-using locales and thus cause code to fail in an expected manner in those locales, instead of unexpectedly/strangely. It would allow the gradual introduction of XPG/4 localization. This has the same degree of intellectual honesty as Garrett's proposal, since it also does not play favorites, with the possible exception of some 7bit programs that failed in international locales failing in a different manner. Since both failure modes were unexpected behaviour to the 8-bit or runic locale residents, I believe this to be acceptable: a strange failure is a strange failure, no matter where it originates, and there is no validity to the argument that one kind of strange is superior to another. The tradeoff between my and Garrett's proposals is that mine drastically reduces the incentive to make code work outside your own locale, while Garrett's risks alienating a large existing user base in order to make the incentive as high as possible. In this way, both are bad; the question is which is "acceptably bad". > > Use ISO 8859-1 as the C locale. > > We already agree. I expect some sort of patch from you or Kaleb. Copy the 8859-1 US locale. No real patch is needed. > > Add a directive to the default .mk files to cause the use of > > XPG/4 instead of XPG/3 when the directive is specified. > > See below. > > Well, here is *below*. > > I not fully understand why mess with linker here. My idea is left > XPG4 inplace, but restrict it to load only XPG3 valid data for now. > In this case it will looks like XPG3 from program point of view, > moreover, large part of my hack (XPG3 restrictions) will be removed too > automatically. > Later we can easily switch to XPG4 by removing those restrictions. This is what we physicists call "hand waving". 8-). This puts another all-or-nothing-choice on the users, bringing your total to two: ,---------------.------------------.------------------.---------------. | Conversion | Garret | Ache | Terry | |---------------+------------------+------------------+---------------| | 7bit | No effect | No effect | No effect | | | | | | | | | | | | | | | <optional> | | | | | | | | | | | | | | | | | | 7->8-bit | | | | | Some 8859-x | | | | | | | | | | | | | | | | | | | | | <all or nothing> | <optional> | | | | | | | | | | | | | v | v | | 8-bit->XPG/3 | | | i18n function | i18n function | | | | | | | | | | | | | | | | | | | <all or nothing> | <all or nothing> | <optional> | | | | | | | | | | | v | v | v | | XPG/3->XPG/4 | Full function | Full function | Full function | `---------------'------------------'------------------'---------------' The ability to link XPG/3 by default and XPG/4 by option is required to support the optional rather than the "all or nothing" transition between "i18n function" and "full function". The reason to "mess with the linker" is so that XPG/4 binaries are not required to be statically linked and we are not required to maintain a full seperate C library, only an XPG/4 library. Otherwise XPG/4 internationalization is second class twice: once because of the effort to go XPG/3->XPG/4, and once because of the link differences and (potentially) the larger static binary. Regards, 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?199510182046.NAA00860>