|
From: | Richard Frith-Macdonald |
Subject: | Re: GNUstep on 64 bit Windows - Patch for gnustep base submitted |
Date: | Mon, 17 Nov 2008 17:48:13 +0000 |
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 haschanged 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 ofthese 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? (Forexample when reading on disk structures) GSConfig.h in base offers someoptions 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).
[Prev in Thread] | Current Thread | [Next in Thread] |