Why is there an internal FcConfig?
This discussion was probably held before somewhere, but I cannot seem to find it.
I am reading into this code, and I keep wondering: why is there an internal FcConfig (src/fccfg.c:41, static FcConfig *_fcConfig;)?
If I understand correctly, there are currently two ways to work with a FcConfig. You can either do it explicitly, by doing something like
FcConfig* config = FcInitLoadConfigAndFonts();
...
FcBool success = FcConfigSubstitute(config, pat, FcMatchPattern);Or implcitly
...
FcBool success = FcConfigSubstitute(NULL, pat, FcMatchPattern);And the NULL will make sure that the internal FcConfig is created. I feel there are two problems with having both an internal and an external state.
First of all, I feel it might be confusing to the user (it was confusing to me). Say, he has its own, custom config and at some point (due to copy-pasting or whatever) accidentally calls a function with config == NULL. Now, Fontconfig silently creates its internal state and finishes correctly. All code works like a charm, but the user gets unexpected results, which might be quite hard to debug.
My second feeling is with the complexity. Because the internal state needs to be checked, managed and threadsafe, fccfg.c is pretty complex. If the user has to handle the FcConfig*, this complexity would probably reduce.
Removing this internal FcConfig will break compatibility, that I understand. Are there other reasons why keeping the internal one is preferred over removing it?