Mon 24 Nov 2014 04:29:15 AM UTC, original submission:
In cffcmap.c:104
FT_DEFINE_CMAP_CLASS(cff_cmap_encoding_class_rec,
sizeof ( CFF_CMapStdRec ),
(FT_CMap_InitFunc) cff_cmap_encoding_init,
(FT_CMap_DoneFunc) cff_cmap_encoding_done,
(FT_CMap_CharIndexFunc)cff_cmap_encoding_char_index,
(FT_CMap_CharNextFunc) cff_cmap_encoding_char_next,
NULL, NULL, NULL, NULL, NULL
)
cff_cmap_encoding_init is:
FT_CALLBACK_DEF( FT_Error )
cff_cmap_encoding_init( CFF_CMapStd cmap )
FT_CMap_InitFunc is:
typedef FT_Error
(*FT_CMap_InitFunc)( FT_CMap cmap,
FT_Pointer init_data );
Note that the number of parameters differs. Calling this function
results in undefined behavior.
ISO/IEC 9899:TC3 (Committee Draft eptermber 7, 2007)
6.5.2.2 Function calls
9 If the function is defined with a type that is not compatible with the
type (of the expression) pointed to by the expression that denotes the
called function, the behavior is undefined.
On certain platforms (c -> js with emscripten) this causes termination of
execution or invalid calls because in the emscripten implementation, function
pointers of different types are stored in different pointer arrays. Incorrect
pointer type here results in indexing of an incorrect array.
Similar suspicious casts exist for:
cff_cmap_unicode_init
t1_cmap_standard_init
t1_cmap_expert_init
t1_cmap_custom_init
t1_cmap_unicode_init
fnt_cmap_init
pfr_cmap_init
Proposed fix attached
|