On Tue, Apr 16, 2013 at 06:12:54AM -0500, Vladimir Támara Patiño wrote: > On Wed, Apr 10, 2013 at 01:48:03PM +0200, Stefan Sperling wrote: > >> + return 1; // If not UTF8 then single byte encoding > > > >No C++ comments, please! > > The attached patch doens't have C++ comments.
Thanks. Regarding your test program, I have a small nit: You've sent a test program that uses the es_CO locale, which probably only exists on your own patched system, so the test program doesn't work elsewhere. Please consider sending tests programs that work on other peoples' systems without modification -- just as a matter of courtesy. Regarding your fix: I've verified that it works, but I think there is a better way of fixing this. It seems strange that the citrus layer is concerned at all with setting the global __mb_cur_max variable, a variable which is actually in the domain of code in the locale/ directory. Consider the following idea: We add a new member to struct _citrus_ctype_rec, called e.g. cc_mb_cur_max, which can be hard-coded to the correct value during definitions of _citrus_ctype_rec objects we use. The generic locale/ code could then set __mb_cur_max based on that constant value, at the bottom of the _xpg4_setrunelocale() function, by pulling the correct value out of the rl->rl_citrus_ctype structure. _citrus_ctype_open() won't have to fiddle with __mb_cur_max anymore, which also fixes another bug: We currently change __mb_cur_max even if setting the locale files after _citrus_ctype_open()! Do you want to try implementing this idea? I believe this idea would result in a smaller diff, too.
