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

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

[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 organization made an interest on me. Looking forward to contribute.

Split the existing fuzz target into many
Above project looks interesting and I would like to get know the mentors to
get started with.

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

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

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

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

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

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

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

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

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