[Devel] Calling convention issue with FreeType 2.1.8

[Rick Hunter]

Hello,

I have been using FreeType 2.1.4 successfully in our project for quite some 
time.  We are statically linking FreeType into our project using Visual 
Studio .NET 2003 as our compiler.  The only modifications I needed to make 
were to change the calling convention of the FreeType project to use 
__fastcall rather than the default setting, since our project uses the 
__fastcall calling convention.  This was easily done using FreeType 2.1.4 
and everything had been happy since.

Recently I tried to update our version of FreeType to use the new 2.1.8 
release.  I performed the same modifications on the project as I did with 
2.1.4 and changed the calling convention to __fastcall.  FreeType 2.1.8 was 
compiled succesfully, and our project linked to it successfully.  (By the 
way, I am using the .NET .sln and .vcproj to compile)  However upon running 
the application (in debug mode) I received a runtime error with the 
following message:

"ESP not saved accross function call, this is usually the result of a call 
to a function defined with a calling convention by a pointer with a 
different calling convention."

This was received when the following call was made in ftobjs.c at line 2090:
   if ( clazz->set_pixel_sizes )
     error = clazz->set_pixel_sizes( face->size,
                                     pixel_width,
                                     pixel_height );

The set_pixel_sizes member of clazz is a function pointer to a 
FT_Size_ResetPixelsFunc function which is declarred as such:
typedef FT_Error
 (*FT_Size_ResetPixelsFunc)( FT_Size  size,
                             FT_UInt  pixel_width,
                             FT_UInt  pixel_height );

The clazz structure above has a static function assigned to set_pixel_sizes, 
but it is cast to the typedef above.  I'm not positive, but I believe that 
because of this that function is using a different calling convention than 
the one specified in the project.  The reason why it is not a compile error 
and it is a runtime error is because of the function pointer cast.  And just 
a note: other functions were called successfully, only when these functions 
are being called through a function pointer in this manner, are there 
issues.

Looking through the mailing list archives I found an email from Soeren 
Muehlbauer (address@hidden) where he has a very similar problem 
regarding calling conventions and runtime errors. (I've attached his email 
below).  The response from Werner at the time was "This should be fixed now 
in the CVS.  David, please check this! Maybe it can be simplified."  I'm not 
sure if Soeren's problem was ever fixed, but that comment was made before 
2.1.8 was released, so I can only assume the fix made it into 2.1.8?

Anyways, sorry for the long-winded email, but I just wanted to make sure all 
the fact were known.  Werner or anyone else, do you have any idea how I can 
go about correcting this problem?  Either in the FreeType sources or our own 
usage of the library?

Thank you,
Rick.

------------------------------------------------------

Hi,

i have built the library as a dll. All seems to be ok. But now i want
to change the calling convention, which is currently cdecl to stdcall.
I edited the lines in ftOption.h.

They now look like this:

#define  FT_EXPORT(x)    extern __declspec(dllexport)  x __stdcall
#define  FT_EXPORT_DEF(x) __declspec(dllexport)  x  __stdcall

It compiles ok. But some calls, for instance FTC_SBitCache_New result
in a GPF. I figured out that there is a struct for each cache. There
are pointers to methods in these struct. The declaration for example
is like the following:

typedef FT_Error
 (*FTC_Cache_InitFunc)( FTC_Cache  cache );

This means implicitly that the default(compiler) calling convention is used.
But the implementation of the function is like this:

FT_EXPORT_DEF( FT_Error )
 ftc_cache_init( FTC_Cache  cache )

As you can see, the calling conventions arent equal. What can i do to
get the stdcall calling convention? Thanks in advance.

--
Best regards,
Soeren Muehlbauer
mailto:address@hidden

_________________________________________________________________
Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! 
http://join.msn.click-url.com/go/onm00200362ave/direct/01/