Hi,
Trying to catch a bug (in which I haven''t succeeded, see my next mail)
I found a suspicious code in fontconfig-2.3.94/src/fclang.c. It says:
=== SNIP ==const FcCharSet *
FcCharSetForLang (const FcChar8 *lang)
{
int i;
int country = -1;
[...]
for (i = 0; i < NUM_LANG_CHAR_SET; i++)
{
switch (FcLangCompare (lang, fcLangCharSets[i].lang)) {
case FcLangEqual:
return &fcLangCharSets[i].charset;
case FcLangDifferentCountry:
if (country == -1)
country = i;
default:
break;
}
}
if (country == -1)
return 0;
return &fcLangCharSets[i].charset;
}
=== SNIP ==
I don''t know what this code exactly stands for, but I have a feeling
that
the last return statement should rather be this:
return &fcLangCharSets[country].charset;
Currently it returns a pointer to a memory segment that is (I don''t
know)
most likely either uninitialized or contains terminating null elements,
since i is guaranteed to equal to NUM_LANG_CHAR_SET, furthermore country has
no real integer meaning, it''s basically just a boolean (either -1 or
not)
and the first "if (country == -1)" testing makes no sense either.
I guess it was rather intended to return the first charset for which the
language at least partially (same lang but different country) matches, which
is remembered in country.
--
Egmont
Egmont Koblinger wrote:> Currently it returns a pointer to a memory segment that is (I don''t know) > most likely either uninitialized or contains terminating null elements, > since i is guaranteed to equal to NUM_LANG_CHAR_SET, furthermore country has > no real integer meaning, it''s basically just a boolean (either -1 or not) > and the first "if (country == -1)" testing makes no sense either. > > I guess it was rather intended to return the first charset for which the > language at least partially (same lang but different country) matches, which > is remembered in country.That is suspicious. Does it fix your problem if you return &fcLangCharSets[country].charset? pat
On Thu, Mar 02, 2006 at 02:35:46PM -0500, Patrick Lam wrote:> Egmont Koblinger wrote: > > Currently it returns a pointer to a memory segment that is (I don''t know) > > most likely either uninitialized or contains terminating null elements, > > since i is guaranteed to equal to NUM_LANG_CHAR_SET, furthermore country has > > no real integer meaning, it''s basically just a boolean (either -1 or not) > > and the first "if (country == -1)" testing makes no sense either. > > > > I guess it was rather intended to return the first charset for which the > > language at least partially (same lang but different country) matches, which > > is remembered in country. > > That is suspicious. Does it fix your problem if you return > &fcLangCharSets[country].charset?No. I thought it would. My happiness lasted for half minute, but then I was disappointed to see that it doesn''t fix it. :-( That code segment is not executed when I start vte or gnome-terminal. That''s why I sent two separate mails, one about this "I don''t know what it fixes" fix :), and another one with my (yet unsolved) "LANG=hu_HU vte" problem. -- Egmont
Egmont Koblinger wrote:> On Thu, Mar 02, 2006 at 02:35:46PM -0500, Patrick Lam wrote: > >>Egmont Koblinger wrote: >> >>>Currently it returns a pointer to a memory segment that is (I don''t know) >>>most likely either uninitialized or contains terminating null elements, >>>since i is guaranteed to equal to NUM_LANG_CHAR_SET, furthermore country has >>>no real integer meaning, it''s basically just a boolean (either -1 or not) >>>and the first "if (country == -1)" testing makes no sense either. >>> >>>I guess it was rather intended to return the first charset for which the >>>language at least partially (same lang but different country) matches, which >>>is remembered in country. >> >>That is suspicious. Does it fix your problem if you return >>&fcLangCharSets[country].charset? > > No. I thought it would. My happiness lasted for half minute, but then I was > disappointed to see that it doesn''t fix it. :-( That code segment is not > executed when I start vte or gnome-terminal. > > That''s why I sent two separate mails, one about this "I don''t know what it > fixes" fix :), and another one with my (yet unsolved) "LANG=hu_HU vte" > problem.I bet that code segment is never executed; it''s been in the fontconfig code since day 1. In any case, I do think it''s still wrong, so I''ll commit the patch that doesn''t fix anything. pat