Custom Query (204 matches)

I have encountered a few cases where a file has a blank EA, with no data, in the middle of the EA list (as shown by FM/2 edit Extended Attributes). RSync, and ZIP, both crash when they encounter such a file. See Crash.txt in RSYNCCRASH.zip for details, and a sample file.

I have not, yet, determined what is actually creating the EAs that cause the problem (see Crash,txt, which describes how I created the file), but neither program should crash when they encounter the problem. It appears that most programs simply drop all of the EAs when they encounter it.

If -export-symbols-regex is given on the libtool command line, it causes the code path that involves NM to deal with exported symbols instead of EMXEXP. This breaks on OS/2 because NM is unable to handle -OMF files and because it somehow results into wrong constructs due to some missing defines. This may be a 2.4.6 regression since Glib uses this switch on OS/2 and it worked well in libtool 2.4.2.

Currently, this defect prevents us from building pango (which also uses this switch).

In fontconfig, according to the docs, each property of a pattern (e.g. FC_FAMILY) may have more than one value (i.e. something like WarpSans plus Helv) and both of these values will be used when matching the pattern with some font set (using e.g. FcFontMatch). It looks to me that our old, r927 code only supported a single value per pattern property. And our OS/2 applications using fontconfig are aware of this fact and never supply it with multi-value patterns (or at least we don't notice any problems when they do).

However, the update of fontconfig to the newest version 2.11.94 in r1170 (and above) brought the upstream FcPattern implementation which supports multi-values and also some matching code (e.g.FcFontSetSort) that utilizes these multi-values. OTOH, there is still some old OS/2 matching code like FcFontMatch (actually, all code in fontconfig.c) that uses only the first value of each property. This creates an obvious inconsistency. We should fix that and make our OS/2 code support multi-values as well (perhaps, by borrowing parts from the upstream fontconfig.c implementation).