Let's see.
FcPattern is a structure with four members: integers
num and
size,
elts_offset of type
intptr_t, and
ref of type
FcRef AKA
int.
FcPatternElt is a structure with two members:
object (of type
FcObject AKA
int), and a pointer
values (to type
FcValueList) forming a linked list.
FcPatternElts(p) evaluates to
((FcPatternElt *)((intptr_t)p + (ptrdiff_t)(p->elts_offset))), i.e.
elts = (FcPatternElt *)((char *)p + p->elts_offset).
Looking at other related stuff, that points to an array of objects at byte offset
elts_offset relative to the original pointer, sorted in order of increasing
object (number identifier).
In
FcPatternObjectInsertElt(),
FcPatternObjectPosition() does a binary search to find the specified
object. If the object is found, FcPatternObjectInsertElt() returns a pointer to it. Otherwise, we get into the if body.
FcPatternObjectCount(p) returns just
p->num, the number of FcPatternElt's in the array, and obviously
p->size is the size of the array.
Now, how is that reallocation supposed to work? Ah yes, that aforementioned FcPatternElts(), although relative to the original pointer, may actually be a completely separate pointer. The line
528,
p->elts_offset = FcPtrToOffset (p, e);, evaluates to
p->elts_offset = (intptr_t)e - (intptr_t)p;, so that FcPatternElts() will yield the possibly realloc()'d pointer.
The FcPatternObjectInsertElt() is used in
src/fcpat.c:FcPatternObjectListAdd(),
src/fcpat.c:FcPatternObjectAddWithBinding(), and
src/fccfg.c:FcConfigPatternAdd().
If we look through the entire
src/fcpat.c file, wherever
->size is used (because that is the "allocated" size of the elts array, it is never reduced or zeroed out. In other words, fontconfig-2.14.2 is not designed to actually release the memory allocated here back to the OS at all.
So, this is a bug, or rather design deficiency, in FontConfig that requires a refactoring, in my opinion.