Re: GNUstep on 64 bit Windows - Patch for gnustep base submitted

[Richard Frith-Macdonald]

On 17 Nov 2008, at 17:27, Fred Kiefer wrote:

> Richard Frith-Macdonald wrote:
> > On 17 Nov 2008, at 14:23, Roland Schwingel wrote:
> >
> > > Apple has defined NSInteger/NSUInteger with Mac OS 10.5 and also has
> > > changed the method signatures for ALL classes showing these  
> > > limitations.
> > > I have seen you have already started to also define these datatypes
> > > and to slowly use it.
> >
> > Yes.
> >
> > > IMHO the whole gnustep should also be adapted to
> > > use NSInteger/NSUInteger to on one side be method compatible with
> > > Mac OS X and on the other side to fully use the potential of
> > > 64bit cpus/operating systems.
> >
> > I agree.
>
> I also support this switch, but I would like to discuss the  
> semantics of
> these defines. Should NSInteger always denote a 64 bit entity on a 64
> bit system and 32 bit on a 32 system?

NSInteger and NSUInteger are specified to be integers whose size  
equals the address size of the system.  So NSInteger variables can  
always store pointers and pointer variables can always store NSInteger/ 
NSUInteger values.

> This will require that we not only change the interface of many  
> methods,
> but also implementation details relying on the tpye int.

Yes, though I think the changes to implementation details are fairly  
limited.

> What types should we use to make sure we have real 32/64 data? (For
> example when reading on disk structures) GSConfig.h in base offers  
> some
> options here.

I think we should use the (nowadays) standard types int32_t, uint32_t,  
int64_t, uint64_t
Long, long ago I implemented our own size specified types, but I'm  
getting rid of all uses of them in favour of the standard types now  
that they are available on most systems (and we can define them on  
systems where they are not available).