[HarfBuzz] Windows build with MSVC 2008

Sebastien Metrot meeloo at meeloo.net
Sat Aug 20 15:41:11 PDT 2011


Hi Behdad,

I finally had some time to check it out tonight and your changes fixed all the problems I saw, but one: we still need a ctor for the hb_prealloced_array_t class.
Mine looks like that:
   hb_prealloced_array_t()
   {
     len = 0;
     allocated = 0;
     array = NULL;
   }

I guess you would make it look like 
hb_prealloced_array_t() { memset(this, 0, sizeof(hb_prealloced_array_t)); }

Many thanks!

S.


On Aug 5, 2011, at 2:01 AM, Behdad Esfahbod wrote:

> Hi,
> 
> I pushed out a few commits that should address your problems.  Please test.
> 
> Cheers,
> behdad
> 
> On 08/03/11 21:46, Sebastien Metrot wrote:
>> On Aug 4, 2011, at 2:46 AM, Behdad Esfahbod wrote:
>> 
>>> 
>>> On 08/03/11 20:39, Sebastien Metrot wrote:
>>>> Hi All,
>>>> 
>>>> I have added harfbuzz-ng to my GUI framework and it now works fine on OSX and iOS. While compiling the code on windows, I had to make some changes to get harfbuzz to build and run:
>>>> - USHORT, SHORT, ULONG and LONG are already defined by the Win32 SDK so I had to #define them in hb-opentype-private.hh:
>>> 
>>> What a weird coincidence!  I just did that yesterday.  Try with master.
>> 
>> Oh, cool will try.
>> 
>>>> - I also had to disable the extern "C" { } declarations, all code now being in .cc files and some functions returning class object, the compiler refuses them. So I changed line 32 of hb_common.h to: # if (defined __cplusplus) && (!defined WIN32)
>>> 
>>> Well, we need those in the public .h files at least.  I'll give it a look
>>> again.  There was some weird reason I added them to .cc files.
>>> 
>>> Which functions return class objects BTW?
>>> 
>> 
>> I just checked and the errors comes from the inclusion of the intrisics headers for the atomic operations. The actual error from the compiler is:
>> 1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\ivec.h(96) : warning C4190: '&' has C-linkage specified, but returns UDT 'M64' which is incompatible with C
>> 1>        C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\ivec.h(77) : see declaration of 'M64'
>> 
>> There are TONS of similar errors for most functions in those headers. I'm pretty sure I saw the non POD error once but it seems I can't trigger it again now.
>> 
>> 
>>> 
>>>> - Last but not least, I noticed what looks like a bug to me: the declaration of the hb_prealloced_array_t template lacks a constructor, so all its data is rubbish if the compiler doesn't blank it or if the memory is not already zeroed, which is the case with visual C++.
>>> 
>>> Interesting.  I'll take a look.  Can you clarify: is the static global
>>> instances you are talking about or any other ones?  I assumed global ones get
>>> zeroed like POD structs in C are.
>>> 
>> 
>> If I remove the ctor I get an access violation in 
>>> 	TextEdit.exe!hb_ot_map_builder_t::feature_info_t::cmp(const hb_ot_map_builder_t::feature_info_t * a=0x0018e744, const hb_ot_map_builder_t::feature_info_t * b=0x8018e718)  Line 171 + 0xc bytes	C++
>> 
>> depending on the font and the text I try to render, a or/and b seem to be pointing to wrong places in memory. I'm unsure about the rules about structs inits in c++ as I mostly don't use them (and I memset them when I do).
>> 
>>> 
>>>> With all these changes I have been able to build harfbuzz and two of my test programs. The bad news is that the first program runs but displays mismatched glyphs (and that's for Latin1 text with the Vera Sans mono font, so I guess it should be pretty simple). The second program seems stuck in a loop in the method hb_ot_map_builder_t::compile(...) with the font Andalus and some arabian text.
>>> 
>>> That's not what I expect...
>> 
>> Ok, there was at least one bug that was mine, Latin1 now seems to work (I was feeding wchar_t to hb_buffer_add_utf32 but wchar_t on windows is actually UCS, I replaced the call with hb_buffer_add_utf16).
>> Concerning the second problem, I have investigated a bit and It seems that the class ht_ot_map_builder_t also lacks a ctor to init current_state. If I add one and init current_state[] to 0, I can get passed the infinite loop and into a crash in MY code that I will look into now ;-).
>> 
>> Thanks for your help :-)
>> 
>> S.
>> 
>> 
>> _______________________________________________
>> HarfBuzz mailing list
>> HarfBuzz at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
>> 




More information about the HarfBuzz mailing list