With freetype 2.7, I re-based the diagnostics patch set. Patch 1 (the updated one from Werner) http://lists.nongnu.org/archive/html/freetype-devel/2016-07/msg00016.html continues to apply as is, so there is not much to say about that.
FontVal 2.0 was shipped with 54 of those enum's. I thought a bit more about the enum-as-string and enum-as-number issue, and beyond 54. It seems to be possible to do both string and number at the macro-expansion stage using the #arg stringification directive, i.e. === +#define DIAGNOSTICS( message, context ) \ + do \ + { \ + if ( diagnostics ) \ + (*diagnostics)( message, #message, \ ... DIAGNOSTICS(_rast_E_INSTR_DEFD_BY_FS, exc ); === and let the C preprocessor expands _rast_E_INSTR_DEFD_BY_FS into _rast_E_INSTR_DEFD_BY_FS, " _rast_E_INSTR_DEFD_BY_FS" (via message, #message ) , Future clients to this API can then use either the enum-as-number or enum-as-string as they see fit, and ignore the other argument. This is assuming there is incentive for another client to happen :-). FreeType will need to have another public header listing the enum (as numbers). That's somewhat easier and more agreeable than enums as struct of both number and string, or enum-as-string. Beyond b54 and towards b59 (I have a b55, and "ELSE found without IF" is related to "EIF found without IF" so will be added together "blindly" without a test file) 3 have test files: EIF found without IF Twilight zone point not set Loop variable not 1 at end of program. This means it was set but not used I have had a look at the nIFs usage in Ins_IF(), etc. I don't think I can re-use that, as the current usage seems to go to zero to terminate the inner-most if/then/else. a few questions: - why is 2nd-level if/then/else seems to be treated differently - without going back to the main loop, and just keeps on with Skip_Code()? - if I add my own exec->nIFs_levels to track the current IF-nested levels, is there a preferred location to add it within the TT_Execution_Context ? For ABI-compatibility, or aesthestic reasons... - along the same line, I'd eventually want to put the messaging function pointer inside TT_Execution_Context->TT_Face->... - is there a preferred place for it? The end, middle somewhere, etc? - about "Twilight zone point not set" - I didn't want to add it in a rush since the freetype code seems to pre-define the 4 corners as zone points? Or there is a comment in the code which suggests so. So this is a question about assumed pre-defined twilight zone points, or whether they exist. I think I am okay with "Loop variable not 1 at end of program. This means it was set but not used" if when I get round to look at that glyph in detail... it should be obvious when I see it... _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel