GNU bug report logs - #52888
29.0.50; font_{delete_unmatched,score} do not handle nil FONT_WEIGHT_INDEX

Previous Next

Full log

View this message in rfc822 format

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 52888 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: bug#52888: 29.0.50; font_{delete_unmatched,score} do not handle nil FONT_WEIGHT_INDEX
Date: Wed, 05 Jan 2022 14:55:02 +0100

>>>>> On Wed, 05 Jan 2022 14:37:56 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    Eli> I'm far from being an expert on Fontconfig programming, but the above
    Eli> use of 'range' looks strange: it's a pointer that starts pointing to
    Eli> some random (potentially invalid) address, and you pass its address to
    Eli> FcPatternGetRange, which presumably assigns to it a valid point.  But
    Eli> doesn't that valid pointer need to be released somehow after we use
    Eli> it?  Or does it point to static area(s)?  I cannot find anything in
    Eli> the Fontconfig documentation about the memory-management protocols for
    Eli> FcValue objects, but maybe we should call FcValueDestroy on it after
    Eli> we are done with it?  Or maybe this is not needed, as this passage
    Eli> from the docs says near the end:

    Eli>   void FcValueDestroy (FcValue v)
    Eli>       Frees any memory referenced by `v'. Values of type FcTypeString,
    Eli>       FcTypeMatrix and FcTypeCharSet reference memory, the other types
    Eli>       do not.

Based on an admittedly quick reading of the fontconfig code, itʼs not
our responsibility to deallocate the FcRange here; it ends up pointing
to memory previously allocated internally by fontconfig.

Robert
-- 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.