Thanks Sebastien. Pushed out.
behdad
On 08/21/11 00:41, Sebastien Metrot wrote:
> 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
>>> [email protected]
>>> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
>>>
>
> _______________________________________________
> HarfBuzz mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
>
_______________________________________________
HarfBuzz mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
