<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED --- - race condition issue?" href="https://bugs.freedesktop.org/show_bug.cgi?id=69845#c12">Comment # 12</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED --- - race condition issue?" href="https://bugs.freedesktop.org/show_bug.cgi?id=69845">bug 69845</a> from <a class="email" href="mailto:freedesktop@behdad.org" title="Behdad Esfahbod <freedesktop@behdad.org>"> Behdad Esfahbod</a> <pre>(In reply to <a href="show_bug.cgi?id=69845#c11">comment #11</a>) > (In reply to <a href="show_bug.cgi?id=69845#c10">comment #10</a>) > > Why this change: > > > > - memset (new->map, '\0', sizeof (new->map)); > > - memcpy (new->map, ls->map, FC_MIN (sizeof (new->map), ls->map_size * > > sizeof (ls->map[0]))); > > + memcpy (new->map, ls->map, sizeof (ls->map)); > > > > It's wrong. > > unrelated to this matter but isn't it a duplicate? is there any assumption > that the size of new->map and ls->map is different? map_size is always set > to NUM_LANG_SET_MAP and no reallocation on map too. hmm, architecture > related thing? that said we have separate caches per architectures. there > shouldn't be the case which we deal with different size of FcChar32. The idea is that whenever we add new orth files, we don't have to bump up the cache version. So, the langset may be coming from a cache file generated by older fontconfig and hence having fewer entries. I added this after hours of very hard to debug issues when this actually happened a few years ago. I don't think it's a bad assumption. Bumping cache version every time we add a language sounds a bit excessive.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>