On Tue, Sep 24, 2013 at 1:06 PM, W. Trevor King <wking@xxxxxxxxxx> wrote: > That would be true if FcListPatternMatchAny wasn't an internal > function: > > $ git --no-pager grep FcListPatternMatchAny > src/fccfg.c: if (FcListPatternMatchAny (patterns->fonts[i], font)) > src/fcint.h:FcListPatternMatchAny (const FcPattern *p, > src/fclist.c:FcListPatternMatchAny (const FcPattern *p, > src/fclist.c: if (FcListPatternMatchAny (p, /* pattern */ > > I'm also not sure it makes sense to have different handling for NULL > FcPatterns and non-NULL FcPatterns with no elements, since the comment > for FcListPatternMatchAny says: Talking about NULL FcPattern being introduced by FcNameParse() would means no valid patterns. given that holding that state and calling FcFontList() would ends up to the same result because of no such fonts matched to that pattern. and usually not expecting to see NULL pattern to any APIs. they should use the empty FcPattern instead. Or applications shouldn't simply continue to work if FcNameParse() failed in this case. dunno. anyway, more assertions may be annoying so I applied this way. any suggestions are welcome. > It also seems like FcListPatternMatchAll would be a more intuitive > name ;). That would imagines different thing in fontconfig semantics FWIW. > With the more robust FcFontList, perhaps the !pat checks should be > removed from fc-match.c and fc-pattern.c? Yes, maybe that's true. > > In any case, the segfault is gone, which is what I really cared about. > If the internal logic makes sense to you, I'm happy enough ;). > > Cheers, > Trevor > > -- > This email may be signed or encrypted with GnuPG (http://www.gnupg.org). > For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -- Akira TAGOH _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
