[Fontconfig] fontconfig: Branch 'master' - 2 commits

[Behdad Esfahbod]

On 13-01-01 12:36 PM, Raimund Steger wrote:
> Behdad Esfahbod wrote:
>> New commits:
>> commit 1fbb0b3b15774c187c697a80fb3c89bc1f3e0006
>> Author: Behdad Esfahbod <behdad at behdad.org>
>> Date:   Sun Dec 30 19:08:42 2012 -0600
>>
>>      Don't warn if an unknown element is used in an expression
>>
>>      The type will be resolved at runtime...
> 
>> [...]
> 
>> diff --git a/src/fcxml.c b/src/fcxml.c
>> index d31caf5..cf9c8dd 100644
>> --- a/src/fcxml.c
>> +++ b/src/fcxml.c
>> @@ -594,6 +594,10 @@ FcTypecheckValue (FcConfigParse *parse, FcType value,
>> FcType type)
>>           return;
>>       if (type == (FcType) -1)
>>           return;
>> +    /* It's perfectly fine to use user-define elements in expressions,
>> +     * so don't warn in that case. */
>> +    if (value == (FcType) -1)
>> +        return;
>>       FcConfigMessage (parse, FcSevereWarning, "saw %s, expected %s",
>>                FcTypeName (value), FcTypeName (type));
>>       }
> 
> Hm, while testing this I noticed that FcPatternDuplicate returns 0 if it comes
> across an element where the FcObjectValidType check fails, such as when a
> string was assigned to the 'dpi' property.
> 
> This causes a coredump in fc-match, which probably has been like this forever;
> only, the warning gave a hint previously which it doesn't do now. (fontconfig
> still prints a warning if FC_DEBUG=4096 (FC_DBG_OBJTYPES) is set though.)
> 
> E. g. for the config:
> 
> <match target="font">
>   <edit name="test_string" mode="assign">
>     <string>test_string_value</string>
>   </edit>
>   <edit name="dpi" mode="assign">
>     <name>test_string</name>
>   </edit>
> </match>
> 
> (which is of course invalid anyway) the following happens:
> 
> sun2:fontconfig)FC_DEBUG=4096 fc-match -v
> FC_DEBUG=4096
> FC_DEBUG=4096
> FcPattern object dpi does not accept value  "test_string_value"Null pattern
> zsh: segmentation fault (core dumped)  FC_DEBUG=4096 fc-match -v
> 
> Maybe the FC_DBG_OBJTYPES warnings would be better off as normal warnings?
> Although this would mean that the user sees at least two warnings in the case
> of a direct assignment (without <name>).
> 
> Everything else works just fine AFAICT.

Thanks for testing.  I think we want the warning at runtime (instead of
parsing time), and I'll fix the coredump.  The only problem is, we can't
pinpoint to which XML file or rule is causing this, but that's not a huge deal
I think, debugging should allow figuring out.

behdad

> Raimund
> 
> 
> 

-- 
behdad
http://behdad.org/