I'm re-writing the CoreBase string formatting function (printf with %@ support) and while going through the printf(), Apple docs and other sources on the internet I ran across a potential problem with some of the assumptions made when defining these types.
I understand that despite being very portable, GNUstep isn't made to work on all platforms, but I'm still going to use an unlikely platform as example...
Anyway, in the Apple docs, they have:
typedef long NSInteger;
typedef unsigned long NSUInteger
typedef long CFIndex;
Yet, the discussion says:
When building 32-bit applications, NSInteger is a 32-bit integer. A 64-bit application treats NSInteger as a 64-bit integer.
This is true on LP64 platforms but not on any other platform. The problem that I see here is that the Apple docs about string formatting say that if you want to format a NSInteger/NSUInteger/CFIndex you should use '%ld' or '%lu'.
GNUstep, on the other hand, defines these values as intptr_t/uintptr_t, which in my opinion is wrong. We essentially assume these types are as long as a pointer, which is true if you assume LP64. However, this assumption is not true for a cross-platform library.
Lastly, I was browsing the web and came across this (
http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html) where int is 16-bits, long is 32-bits and intptr_t is 16-bits. I realize AVR is not a target, but I just wanted to use it as another example where long is not equivalent to intptr_t. And who known, someone might want to use it in the future.
I would like to suggest typedef'ing NSInteger/NSUInteger/CFIndex as long. That way we can correctly format these integers across all platforms supported by GNUstep.