Re: [ft-devel] LLP64 model outside Win64

>>> - if ( FT_List_Find( >composites, >>> - FT_UINT_TO_POINTER( glyph_index ) ) ) >>> + if ( FT_List_Find( >composites, index ) ) >> >> How shall this work? You are going to store pointers to integers >> in a list. As a consequence, two identical integers can

Re: [ft-devel] LLP64 model outside Win64

On Sun, Feb 25, 2018 at 4:21 PM, Werner LEMBERG wrote: >>> Certainly, if you are going to dynamically allocate a slot for it. >>> I tried to avoid that. >> >> Totally untested, but why wouldn't this work? >> >> [...] >> >> - if ( FT_List_Find( >composites, >> -

Re: [ft-devel] LLP64 model outside Win64

>> Certainly, if you are going to dynamically allocate a slot for it. >> I tried to avoid that. > > Totally untested, but why wouldn't this work? > > [...] > > - if ( FT_List_Find( >composites, > - FT_UINT_TO_POINTER( glyph_index ) ) ) > + if ( FT_List_Find(

Re: [ft-devel] LLP64 model outside Win64

On Tue, Feb 13, 2018 at 4:39 AM, Chris Liddell wrote: > Using C99 types, with sane fallbacks makes sense, but using the more > invasive parts of C99 (like mixing declarations and code) could be > problematic. This is basically what FreeType is doing already. FreeType

Re: [ft-devel] LLP64 model outside Win64

On Mon, Feb 12, 2018 at 4:39 PM, Werner LEMBERG wrote: >> 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

Re: [ft-devel] LLP64 model outside Win64

On 13/02/18 07:17, Werner LEMBERG wrote: >>> 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

Re: [ft-devel] LLP64 model outside Win64

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

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,

Re: [ft-devel] LLP64 model outside Win64

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

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

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

> 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

Re: [ft-devel] LLP64 model outside Win64

+#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

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

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

Re: [ft-devel] LLP64 model outside Win64

>>> >>> (void *)(((char *)0) + (x)) >>> >> >> Wow! Very cool! >> >> >> I'm fairly sure that's undefined in C standard as well. My first impression also... > [...] You can only do pointer arithmetic within an allocate array. > All else is undefined. Which makes sense for same reasons that >

Re: [ft-devel] LLP64 model outside Win64

On Feb 11, 2018 8:15 PM, "Alexei Podtelezhnikov" wrote: (void *)(((char *)0) + (x)) > > Wow! Very cool! > > > I'm fairly sure that's undefined in C standard as well. (void *)((char *)NULL + (x)) ?? Yes. C99 has: """ 8 When an expression that has integer

Re: [ft-devel] LLP64 model outside Win64

(void *)(((char *)0) + (x)) > > Wow! Very cool! > > > I'm fairly sure that's undefined in C standard as well. (void *)((char *)NULL + (x)) ?? ___ Freetype-devel mailing list Freetype-devel@nongnu.org

Re: [ft-devel] LLP64 model outside Win64

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. ___ Freetype-devel mailing list Freetype-devel@nongnu.org

Re: [ft-devel] LLP64 model outside Win64

>>> >>> (void *)(((char *)0) + (x)) >>> Wow! Very cool! ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

On Sun, Feb 11, 2018 at 7:30 PM, Werner LEMBERG wrote: > >>> (void*)(size_t)(x) should be safe, c90, and warning-less. >> >> You assume that all machines have a flat, linear memory model ;-( >> >> The "safe", portable way is to use >> >> (void *)(((char *)0) + (x)) >> >> to

Re: [ft-devel] LLP64 model outside Win64

>> (void*)(size_t)(x) should be safe, c90, and warning-less. > > You assume that all machines have a flat, linear memory model ;-( > > The "safe", portable way is to use > > (void *)(((char *)0) + (x)) > > to cast an integer to a void pointer, and use > > (ptrdiff_t)((char *)(x)) -

Re: [ft-devel] LLP64 model outside Win64

On Sun, Feb 11, 2018 at 6:02 AM, Alexei Podtelezhnikov wrote: > (void*)(size_t)(x) should be safe, c90, and warning-less. You assume that all machines have a flat, linear memory model ;-( The "safe", portable way is to use (void *)(((char *)0) + (x)) to cast an integer

Re: [ft-devel] LLP64 model outside Win64

(void*)(size_t)(x) should be safe, c90, and warning-less. sizeof(size_t)==sizeof(void*) everywhere I could test. This is not guaranteed but the contrary is suspicious. I'll commit this getting rid of the macro. ___ Freetype-devel mailing list

Re: [ft-devel] LLP64 model outside Win64

>> -#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_POINTER( x ) (void*)(unsigned long)(x) >> -#endif >>