On Saturday, 16 September 2017 at 12:34:58 UTC, nkm1 wrote:
On Saturday, 16 September 2017 at 03:06:24 UTC, Timothy Foster
wrote:
[...]
[...]
So it appears I'm screwed then.
Example:
typedef enum FT_Size_Request_Type_
{
FT_SIZE_REQUEST_TYPE_NOMINAL,
FT_SIZE_REQUEST_TYPE_REAL_DIM,
FT_SIZE_REQUEST_TYPE_BBOX,
FT_SIZE_REQUEST_TYPE_CELL,
FT_SIZE_REQUEST_TYPE_SCALES,
FT_SIZE_REQUEST_TYPE_MAX
} FT_Size_Request_Type;
typedef struct FT_Size_RequestRec_
{
FT_Size_Request_Type type;
FT_Long width;
FT_Long height;
FT_UInt horiResolution;
FT_UInt vertResolution;
} FT_Size_RequestRec;
FT_Size_Request_Type_ could be represented by char. Maybe the
compiler makes it an int, maybe not.
Maybe the compiler makes 'FT_Size_Request_Type_' char sized, but
then pads 'FT_Size_RequestRec_' to align 'width' to 4 bytes...or
maybe not.
Maybe a member of 'FT_Size_Request_Type_' sits right before a
char or bool in some struct..so can't rely on padding.
I don't really see a way to deal with this aside from branching
the entire library and inserting something like
'FT_SIZE_REQUEST_TYPE__FORCE_INT = 0xFFFFFFFF' into every enum
incase the devs used it in a struct.
