This is essentially a mechanical conversion, adding inclusion of
`FT_INTERNAL_DEBUG_H' where necessary, and providing the macros for
stand-alone compiling modes of the rasterizer modules.
To convert the remaining occurrences of FT_Err_XXX and friends it is
necessary to rewrite the code. Note, however, that it doesn't harm
if some cases are not handled since FT_THROW is a no-op.
* include/freetype/internal/ftserv.h (FT_SERVICE_UNAVAILABLE): Use
`logical not' operator instead of negation. The idea is that `~'
returns exactly the data type enforced by the cast to a pointer (be
it 32bit or 64bit or whatever), while a negative integer has not
this flexibility.
* src/cache/ftccmap.c (FTC_CMAP_UNKNOWN): Ditto.
* src/truetype/ttgxvar.c (ALL_POINTS, TT_Get_MM_Var): Ditto.
* src/type/t1load.c (T1_Get_MM_Var): Ditto.
(parse_blend_axis_types): Use cast.
* src/bdf/bdflib.c (_bdf_readstream): Use cast.
* src/bdf/bdflib.c (_bdf_list_ensure): Bring code in sync with
comment before `_bdf_list_split', this is, really allocate at least
five `field' elements.
* src/bdf/bdflib.c (_bdf_parse_glyphs) <DWIDTH, BBX>: Abort if
_BDF_ENCODING isn't set. We need this because access to the `glyph'
variable might be undefined otherwise.
ENCODING now covers the whole Unicode range.
Note, however, that this change is quite expensive since it
increases the size of three arrays by almost 400kByte in total. The
right fix is to replace the logic with something smarter.
Additionally, there exist very old BDFs for three-byte CCCII
encoding which exceeds the range of Unicode (another reason to have
a smarter logic).
* src/bdf/bdf.h (bdf_font_t): Increase size of `nmod' and `umod'
arrays.
* src/bdf/bdflib.c (bdf_parse_t): Increase size of `have' array.
* src/bdf/bdflib.c (_bdf_readstream): Use special error code to
indicate a redo operation.
(_bdf_parse_start): Handle `CHARS' keyword here too and pass current
input line to `_bdf_parse_glyph'.
* include/freetype/fterrdef.h
(BDF_Err_Missing_Fontboundingbox_Field): New error code.
* src/bdf/bdflib.c (_bdf_parse_start): Check for missing
`FONTBOUNDINGBOX' field.
Avoid memory leak if there are multiple `FONT' lines (which is
invalid but doesn't hurt).
extern const FT_Module_Class
(or similar for C++). However, the actual types of the variables
being declared are often different, e.g., FT_Driver_ClassRec or
FT_Renderer_Class. (Some are, indeed, FT_Module_Class.)
This works with most C compilers (since those structs begin with an
FT_Module_Class struct), but technically it's undefined behavior.
To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7
paragraph 2:
All declarations that refer to the same object or function shall
have compatible type; otherwise, the behavior is undefined.
(And they are not compatible types.)
Most C compilers don't reject (or even detect!) code which has this
issue, but the GCC LTO development branch compiler does. (It
outputs the types of the objects while generating .o files, along
with a bunch of other information, then compares them when doing the
final link-time code generation pass.)
Patch from Savannah bug #25133.
* src/base/ftinit.c (FT_USE_MODULE): Include variable type.
* builds/amiga/include/freetype/config/ftmodule.h,
include/freetype/config/ftmodule.h, */module.mk: Updated to declare
pass correct types to FT_USE_MODULE.
(cff_face_done), src/pfr/pfrobjs.c (pfr_face_done),
src/pcf/pcfdrivr.c (PCF_Face_Done), src/cid/cidobjs.c
(cid_face_done), src/bdf/bdfdrivr. (BDF_Face_Done),
src/sfnt/sfobjs.c (sfnt_face_done): Protect against face == 0.
Reported by Graham Asher.
