freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ft-devel] Re: ABI breakage in 2.3.8 (bad bad bad !!)


From: Deron Kazmaier
Subject: [ft-devel] Re: ABI breakage in 2.3.8 (bad bad bad !!)
Date: Tue, 03 Mar 2009 08:49:01 -0700
User-agent: Thunderbird 2.0.0.19 (Macintosh/20081209)

David Turner wrote:
Hello,

I'm currently updating the Android FreeType sources to the latest CVS. In doing so, I noticed something that unfortunately escaped me before that: we added a new field to a publicly declared structure, thus breaking the ABI.

More specifically, the declaration of PS_FontInfoRec in include/freetype/t1tables.h is now:

typedef struct  PS_FontInfoRec_
  {
    FT_String*  version;
    FT_String*  notice;
    FT_String*  full_name;
    FT_String*  family_name;
    FT_String*  weight;
    FT_Long     italic_angle;
    FT_Bool     is_fixed_pitch;
    FT_Short    underline_position;
    FT_UShort   underline_thickness;

*    /* since 2.3.8 */

    FT_UShort   fs_type;
*
  } PS_FontInfoRec;

the problem is that this structure can be allocated by the user (either in the heap or the stack), e.g. when calling
a function like FT_Get_PS_Font_Info declared as:

FT_EXPORT( FT_Error )
FT_Get_PS_Font_Info( FT_Face      face,
                     PS_FontInfo  afont_info );

*This is very bad* !!.

It means that any client code that was built against 2.3.7 or older will now experience a nice silent stack or heap memory corruption whenever it calls this function in 2.3.8.

I suggest that we do the following instead:

    * remove the field from the definition
    * provide a new function to retrieve the corresponding
      information, as in FT_Get_PS_FsType() or whatever, that will not
      break the ABI
    * release 2.3.9 ASAP explaining why.

I really hope that there isn't any code that relies on this new field out there.

Generalyl speaking, we should *NOT* add fields to public structures, except a very few instances where we know that the corresponding object should never be stack or heap allocated by the user (FT_Face or FT_GlyphSlot for example). Even in these cases, I'd really prefer that we discuss such changes on the development mailing list before hand.

- David


Thanks for catching this. My code is vulnerable to this. I've changed my code to leave extra bytes after the structure just to be safe.

Deron




reply via email to

[Prev in Thread] Current Thread [Next in Thread]