gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Size of NSInteger/NSUInteger/CFIndex


From: Eric Wasylishen
Subject: Re: Size of NSInteger/NSUInteger/CFIndex
Date: Tue, 20 Aug 2013 17:29:26 -0600

Hey Stef,

I think what GNUstep is doing is OK...

On 2013-08-20, at 3:34 PM, Stefan Bidi <address@hidden> wrote:

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.

It's tricky,  because we don't have a definitive specification.

I don't think the "typedef long NSInteger" mentioned in the docs is the final/proper definition of NSInteger. For example, on OS X 10.8, NSInteger can be defined as 'int' under some circumstances.

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

This is from a table in "String Programming Guide", right? I think you may have missed the "Considerations" column which says to cast the value to a long when using the %ld format specifier.

This seems to be the accepted interpretation on stackoverflow as well:

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.

Hope my point addresses your concern.

Cheers,
Eric

reply via email to

[Prev in Thread] Current Thread [Next in Thread]