[Top][All Lists]

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

[Devel] Calling convention issue with FreeType 2.1.8

From: Rick Hunter
Subject: [Devel] Calling convention issue with FreeType 2.1.8
Date: Tue, 08 Jun 2004 11:26:08 -0700


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_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,



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:

 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

Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage!

reply via email to

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