Re: [ft-devel] LLP64 model outside Win64

[Werner LEMBERG]

>>> -  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 have
>> different pointers.  How will you then find out whether such an
>> integer is already in the list?
> 
> I was thinking about glyph indexes as they appear in the glyf table,
> which have fixed offsets/pointers.

OK, this might work, however, I couldn't deduce this from your sample
code :-)

> Does current implementation work for ellipsis …?

I don't understand this question.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[Alexei Podtelezhnikov]

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,
>> - 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 have different
> pointers.  How will you then find out whether such an integer is
> already in the list?

I was thinking about glyph indexes as they appear in the glyf table,
which have fixed offsets/pointers. You, however, talk about table
reallocations.

Does current implementation work for ellipsis …?

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[Werner LEMBERG]

>> 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( >composites, index ) )

How shall this work?  You are going to store pointers to integers in a
list.  As a consequence, two identical integers can have different
pointers.  How will you then find out whether such an integer is
already in the list?

Actually, only the FT_UINT_TO_POINTER macro makes `FT_List_Find' work
for this task.  You need a different function if you don't like this,
for example, putting the glyph indices into a hash and checking
whether a new value is already present.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[Alexei Podtelezhnikov]

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 gains speed
from "long long" on LLP64:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/builds/unix/ftconfig.in#n301
We suppress the long long warning while enforcing ANSI otherwise. This
does not cover Visual C++ unfortunately, which still needs
FT_CONFIG_OPTION_FORCE_INT64. I would actually propose flipping the
option to _AVOID_INT64 for ancient platforms and embracing long long
by default.

Here is anther place where we use embrace long long, again leaving
Visual C++ behind:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/include/freetype/internal/ftcalc.h#n188

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[Alexei Podtelezhnikov]

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

Totally untested, but why wouldn't this work?

diff --git a/src/truetype/ttgload.c b/src/truetype/ttgload.c
index 32ed34a..efb7c3c 100644
--- a/src/truetype/ttgload.c
+++ b/src/truetype/ttgload.c
@@ -1508,7 +1508,7 @@
   /*   */
   static FT_Error
   load_truetype_glyph( TT_Loader  loader,
-   FT_UIntglyph_index,
+   FT_UInt*   index,
FT_UIntrecurse_count,
FT_Boolheader_only )
   {
@@ -1518,6 +1518,7 @@
 TT_Face face = loader->face;
 FT_GlyphLoader  gloader  = loader->gloader;
 FT_Bool opened_frame = 0;
+FT_UInt glyph_index  = *index;

 #ifdef FT_CONFIG_OPTION_INCREMENTAL
 FT_StreamRecinc_stream;
@@ -1783,22 +1784,13 @@
   /* normalize the `n_contours' value */
   loader->n_contours = -1;

-  /*
-   * We store the glyph index directly in the `node->data' pointer,
-   * following the glib solution (cf. macro `GUINT_TO_POINTER') with a
-   * double cast to make this portable.  Note, however, that this needs
-   * pointers with a width of at least 32 bits.
-   */
-
-
   /* clear the nodes filled by sibling chains */
   node = ft_list_get_node_at( >composites, recurse_count );
   for ( node2 = node; node2; node2 = node2->next )
-node2->data = (void*)FT_ULONG_MAX;
+node2->data = NULL;

   /* check whether we already have a composite glyph with this index */
-  if ( FT_List_Find( >composites,
- FT_UINT_TO_POINTER( glyph_index ) ) )
+  if ( FT_List_Find( >composites, index ) )
   {
 FT_TRACE1(( "TT_Load_Composite_Glyph:"
 " infinite recursion detected\n" ));
@@ -1807,13 +1799,13 @@
   }

   else if ( node )
-node->data = FT_UINT_TO_POINTER( glyph_index );
+node->data = (void*)index;

   else
   {
 if ( FT_NEW( node ) )
   goto Exit;
-node->data = FT_UINT_TO_POINTER( glyph_index );
+node->data = (void*)index;
 FT_List_Add( >composites, node );
   }

@@ -2019,7 +2011,7 @@
   num_base_points = (FT_UInt)gloader->base.outline.n_points;

   error = load_truetype_glyph( loader,
-   (FT_UInt)subglyph->index,
+   >index,
recurse_count + 1,
FALSE );
   if ( error )
@@ -2773,7 +2765,7 @@
 {
   /* for the bbox we need the header only */
   (void)tt_loader_init( , size, glyph, load_flags, TRUE );
-  (void)load_truetype_glyph( , glyph_index, 0, TRUE );
+  (void)load_truetype_glyph( , _index, 0, TRUE );
   tt_loader_done(  );
   glyph->linearHoriAdvance = loader.linear;
   glyph->linearVertAdvance = loader.vadvance;
@@ -2818,7 +2810,7 @@
 glyph->outline.flags = 0;

 /* main loading loop */
-error = load_truetype_glyph( , glyph_index, 0, FALSE );
+error = load_truetype_glyph( , _index, 0, FALSE );
 if ( !error )
 {
   if ( glyph->format == FT_GLYPH_FORMAT_COMPOSITE )

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[Chris Liddell]

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 platform except of Win64, C99 compiler is needed" would be
>> enough, if Pierre's guessing is correct.
> 
> Hmm.  Even the dinosaur called `emacs' moved to C99 a few years
> ago :-) While being conservative, it doesn't make sense in case
> everyone already moved on – I've looked into Wikipedia's C99 page, and
> it seems that there aren't any major compilers that don't support it
> (at least the very decent set of changes we would need or use).

The concern is installed bases of systems like AIX, HP-UX, OpenVMS that
haven't been updated in some time, and using the default C compiler.
With Ghostscript, we regularly get reports from such users (not to
mention Windows 95/98/ME, NT 4.0, OS/2, etc, etc - !).

It is odd that they insist on using obsolete hardware and operating
systems, but want the latest releases of other software!

Using C99 types, with sane fallbacks makes sense, but using the more
invasive parts of C99 (like mixing declarations and code) could be
problematic.

>> 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.  I
>> feel it's overkill to close C89 support just to keep this method in
>> LLP64 on the platforms which we have not known their names yet.
> 
> I still vote for the possibility to change FT_UINT_TO_POINTER in a
> configuration file, for example with some code in `ftstdlib.h'.

I guess that would come under the heading of "sane fallback" mentioned
above.

Chris



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[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" would be
> enough, if Pierre's guessing is correct.

Hmm.  Even the dinosaur called `emacs' moved to C99 a few years
ago :-) While being conservative, it doesn't make sense in case
everyone already moved on – I've looked into Wikipedia's C99 page, and
it seems that there aren't any major compilers that don't support it
(at least the very decent set of changes we would need or use).

> 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.  I
> feel it's overkill to close C89 support just to keep this method in
> LLP64 on the platforms which we have not known their names yet.

I still vote for the possibility to change FT_UINT_TO_POINTER in a
configuration file, for example with some code in `ftstdlib.h'.

> If we have a time machine, we should suggest to have an union
> instead of void pointer in FT_ListRec X-(

Indeed.


Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[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, suzuki toshiya 
 wrote:
 

 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 suggest to have an union
> instead of void pointer in FT_ListRec X-(
> 
> 
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
> 


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel


   ___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[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 should suggest to have an union
> instead of void pointer in FT_ListRec X-(
> 
> 
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
> 


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[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 the total migration
to C99. "For LLP64 platform except of Win64, C99 compiler is
needed" would be enough, if Pierre's guessing is correct.

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. I feel it's overkill to close C89 support just to
keep this method in LLP64 on the platforms which we have not
known their names yet.

Regards,
mpsuzuki

P.S.
If we have a time machine, we should suggest to have an union
instead of void pointer in FT_ListRec X-(


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[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: arithmetic on a null pointer treated as a cast from integer to pointer 
is a GNU extension [-Wnull-pointer-arithmetic]

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[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 fine, it seems.  Up to now we only got
reports about compiler warnings but no failures.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[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 untied from Windows, but it
>> should be a portable solution that works with pre-C99 compilers
>> also.
>
> C99 is 20 years old.  At work where we tend to be a bit conservative
> about compilers and environment, even for embedded targets our
> current compiler support it just my 2cents

Hmm.  Using C99 would certainly simplify life.

Maybe we can announce in the forthcoming release that we are switching
to C99 later on.

Comments?


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[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 FT_UINT_TO_POINTER( x ) (void*)(unsigned long)(x)
>>> -#endif
>>> +#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 untied from Windows, but it
> should be a portable solution that works with pre-C99 compilers also.
C99 is 20 years old. At work where we tend to be a bit conservative
about compilers and environment,
even for embedded targets our current compiler support it
just my 2cents
-- 
    Pierre


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[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 pointer to the
glyph index instead of stuffing the integer into the pointer? That is
the root cause of this mess. It does look like integer to pointer
conversion is ill-defined and should be avoided. Here is another
warning quote from C99 (6.3.2.3):

An integer may be converted to any pointer type. Except as previously
specified, the
result is implementation-defined, might not be correctly aligned,
might not point to an
entity of the referenced type, and might be a trap representation.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[Werner LEMBERG]

>>>
>>>   (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
> Roland mentioned (segmented architectures.)

I think we should just ignore such segmented architectures by default.
Instead, we should make `FT_UINT_TO_POINTER' configurable by the user
so that he or she has a chance to override it, should this be ever
necessary.


Werer

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[Behdad Esfahbod]

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 type is added to or subtracted from a
pointer, the
result has the type of the pointer operand. If the pointer operand points
to an element of
an array object, and the array is large enough, the result points to an
element offset from
the original element such that the difference of the subscripts of the
resulting and original
array elements equals the integer expression. In other words, if the
expression P points to
the i-th element of an array object, the expressions (P)+N (equivalently,
N+(P)) and
(P)-N (where N has the value n) point to, respectively, the i+n-th and
i−n-th elements of
the array object, provided they exist. Moreover, if the expression P points
to the last
element of an array object, the expression (P)+1 points one past the last
element of the
array object, and if the expression Q points one past the last element of
an array object,
the expression (Q)-1 points to the last element of the array object. If
both the pointer
operand and the result point to elements of the same array object, or one
past the last
element of the array object, the evaluation shall not produce an overflow;
otherwise, the
behavior is undefined. If the result points one past the last element of
the array object, it
shall not be used as the operand of a unary * operator that is evaluated.
"""

Ie. You can only do pointer arithmetic within an allocate array. All else
is undefined. Which makes sense for same reasons that Roland mentioned
(segmented architectures.)
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[Alexei Podtelezhnikov]

   (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
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[Behdad Esfahbod]

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
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[Alexei Podtelezhnikov]

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

[Roland Mainz]

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 cast an integer to a void pointer, and use
>>
>>   (ptrdiff_t)((char *)(x)) - ((char *)0)
>>
>> to cast a pointer to an integer.
>
> Interesting.  Can you name an example of a machine with a non-linear
> memory model?

24bit/32bit embedded CPU designs, typically designs predating the
widespread adoption of 64bit address space& For example i960
can implement one-address-space-per-object-type - for those who
remember C64's "banking": Sort of One-bank-per-object-type. In such a
scenario a pointer is only valid for the type it was used for since
the same "integer" value can refer to a completely different chunk of
memory for another object type.

A more classical scenario is data& separation as in the
https://en.wikipedia.org/wiki/Harvard_architecture

That's why the wording in the ISO >= C89 standard has a bit more
complex wording about pointer differences, but I can't quote them
since my book 
(https://www.amazon.de/Annotated-ANSI-Standard-Programming-Languages-C/dp/0078819520/ref=sr_1_1)
is a few 100km away right now...



Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.ma...@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&& programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[Werner LEMBERG]

>>  (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)) - ((char *)0)
>
> to cast a pointer to an integer.

Interesting.  Can you name an example of a machine with a non-linear
memory model?


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[Roland Mainz]

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 to a void pointer, and use (ptrdiff_t)((char *)(x)) -
((char *)0) to cast a pointer to an integer. >



Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.ma...@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&& programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[Alexei Podtelezhnikov]

 (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
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LLP64 model outside Win64

[Werner LEMBERG]

>> -#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
>> +#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 untied from Windows, but it
should be a portable solution that works with pre-C99 compilers also.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel