Re: [Devel] 16, 32, and 64 bit ints [was: Patch needed to compile freetype-2.0.1 on Windows XP64 Beta 1]

[Henrik Grubbström]

On Sat, 10 Mar 2001, Tom Kacvinsky wrote:

> One of my points is that I wanted to look at the casts (I failed to mention 
> this
> the first time).  Casts are fine, but the more we can avoid them, the better.

Agreed.

> I want to investigate how we can use a 32 bit int as FT_Long on a 64 bit box 
> and
> avoid some of the issues we have seen, etc...  That is, for those things we
> know are supposed to be 32 bits wide, use int32_t, or some such.  This would 
> go
> a long way torwards getting rid of unnecessary casts and make the code more 
> robust
> for 64 bit and 16 bit platforms, etc...

Sounds reasonable.

> There already is some code in FT that takes this into account (FT_Int16, 
> FT_Int32,
> etc...), but that is for specific things.  I'd like to see this propogated 
> through
> out FT2.  Use of long on a 64 bit box for what is supposed to be a 32 bit int 
> has
> been a problem in the past, which we cleaned up by using casts.  Thre has got 
> to be
> a better way of doing all of this...

Note that a long on a 64-bit cpu not necessarily is 64-bit. Eg the cl & ecl
compilers have a 32-bit long. The 64-bit type is called __int64. The reason
for this is most likely for compatibility reasons (structs etc won't change
size when you change compiler from IA32 to IA64).

I recommend using ptrdiff_t and size_t to hold values which result from
pointer arithmetic (that's after all what they exist for).

> As we don't use autoconf on *all* platforms, we will have to do this with 
> macro
> magic.
> 
> I don't think I am the only one that feels this way...  I'll have to go dig 
> through
> my mail to find out the other "culprits."

To find potential places where information is lost due to casts, I
suggest using Intel's ecl {,cross-}compiler for WIN64/IA64, since it
complains even on explicit casts.

> What do you think about that?

Sounds good. I did the same for our software (Pike) ~ a year ago.

> Tom

--
Henrik Grubbström                                       address@hidden
Roxen Internet Software AB