On Mon, Feb 12, 2018 at 1:07 AM, Werner LEMBERG wrote:
>
(void *)(((char *)0) + (x))
>>>
>>> Wow! Very cool!
>>>
>>>
>>> I'm fairly sure that's undefined in C standard as well.
>
> My first impression also...
Can we properly use the FT_List data field as an actual pointer to the
On 09/02/2018 16:32, Werner LEMBERG wrote:
>>> -#ifdef _WIN64
>>> - /* only 64bit Windows uses the LLP64 data model, i.e., */
>>> - /* 32bit integers, 64bit pointers */
>>> -#define FT_UINT_TO_POINTER( x ) (void*)(unsigned __int64)(x)
>>> -#else
>>> -#define FT_UINT_TO_POINTE
+#define FT_UINT_TO_POINTER( x ) (void*)(uintptr_t)(x)
>>>
>>> Strangely, uintptr_t never came up in
>>> https://savannah.nongnu.org/bugs/index.php?50560
>>> It is C99 though.
>>
>> Exactly. Thus we cannot use it (at least not unconditionally). I
>> don't mind if the LLP64 data model gets u
Hi,
I am eager to take part in GSoC 2018 in the project that aims to covert the
documenataion of FreeType to from HTML to Markdown. Could anyone please
guide me as to where I should be starting? I have coded in Python for about
3 years now and am comfortable in it.
Regards,
Somnath Rakshit
__
> Can we properly use the FT_List data field as an actual pointer to
> the glyph index instead of stuffing the integer into the pointer?
Certainly, if you are going to dynamically allocate a slot for it.
I tried to avoid that.
> That is the root cause of this mess.
Well, the `mess' works just f
On Sun, 11 Feb 2018 20:01:25 -0800, Behdad Esfahbod said:
>On Feb 11, 2018 7:53 PM, "Alexei Podtelezhnikov" wrote:
>
(void *)(((char *)0) + (x))
>
>Wow! Very cool!
>
>
>I'm fairly sure that's undefined in C standard as well.
Indeed. clang warns:
warning: arithmetic on a null po
Dear Werner,
Werner LEMBERG wrote:
> Hmm. Using C99 would certainly simplify life.
>
> Maybe we can announce in the forthcoming release that we are switching
> to C99 later on.
>
> Comments?
I have no objection to have some conditional parts for C99-
specific feature, but I feel negative with
suzuki toshiya wrote:
> The usage of FT_UINT_TO_POINTER() macro is only used to store
> the 32-bit integer (GID) into the storage of FT_List object
> directly.
Oh, I slipped to quote Alexei for finding this. Thank you, Alexei!
> Regards,
> mpsuzuki
>
> P.S.
> If we have a time machine, we should
Hi all,
I'm Gayan Kavirathne, a final year computer science & Engineering
undergraduate at University of Moratuwa - Sri Lanka.
I have been working on project which converts freeType,openType and
RegularType fonts to unicode. It currently supports only for south east
asian fonts only.
So your organ
How about casting it to size_t instead of 'unsigned long' in the else case? It
should normally work. Anyway, assuming that size_t is the same size as a
pointer is better than doing the same with unsigned long which happens to be
different with LLP64.
On Monday, February 12, 2018 9:02 PM,
>> Maybe we can announce in the forthcoming release that we are
>> switching to C99 later on.
>
> I have no objection to have some conditional parts for C99-specific
> feature, but I feel negative with the total migration to C99. "For
> LLP64 platform except of Win64, C99 compiler is needed" wou
11 matches
Mail list logo