Re: [ft-devel] LLP64 model outside Win64

2018-02-12 Thread Werner LEMBERG
>> 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"

Re: [ft-devel] LLP64 model outside Win64

2018-02-12 Thread Ruslan Nikolaev
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,

[ft-devel] Contributing to the organization -GSOC

2018-02-12 Thread Gayan Kavirathne
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

Re: [ft-devel] LLP64 model outside Win64

2018-02-12 Thread suzuki toshiya
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

Re: [ft-devel] LLP64 model outside Win64

2018-02-12 Thread suzuki toshiya
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

Re: [ft-devel] LLP64 model outside Win64

2018-02-12 Thread Sean McBride
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:

Re: [ft-devel] LLP64 model outside Win64

2018-02-12 Thread Werner LEMBERG
> 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

[ft-devel] Enquiry about GSoC project

2018-02-12 Thread Somnath Rakshit
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

Re: [ft-devel] LLP64 model outside Win64

2018-02-12 Thread Werner LEMBERG
+#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

Re: [ft-devel] LLP64 model outside Win64

2018-02-12 Thread Pierre Hanser
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

Re: [ft-devel] LLP64 model outside Win64

2018-02-12 Thread Alexei Podtelezhnikov
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