[
https://issues.apache.org/jira/browse/THRIFT-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309159#comment-14309159
]
Jeremy W. Sherman commented on THRIFT-2180:
-------------------------------------------
Finding that a primary issue is lack of 64-bit cleanliness in some of the basic
library protocols. For example, TTransport includes this oddly inconsistent
pair of declarations:
{code}
- (int) readAll: (uint8_t *) buf offset: (int) off length: (int) len;
- (void) write: (const uint8_t *) data offset: (unsigned int) offset length:
(unsigned int) length;
{code}
Note the shift in the len/length argument from int when reading to unsigned int
when writing. These would be NSUInteger in a higher level API, but likely
should be size_t here, given the other C types in play. Offset could be off_t,
but that's needlessly signed; size_t would likely be appropriate there, as well.
> Integer types issues in Cocoa lib on ARM64
> ------------------------------------------
>
> Key: THRIFT-2180
> URL: https://issues.apache.org/jira/browse/THRIFT-2180
> Project: Thrift
> Issue Type: Bug
> Components: Cocoa - Library
> Affects Versions: 0.9.1
> Environment: ARM64, iOS, xcode5
> Reporter: Sébastien martini
>
> When compiling the Cocoa library (using the current master) for iOS on ARM64,
> xcode5 highlights several integer types warnings.
> Several of these instances are originated from the issue that the [NSData
> length] method returns an NSUInteger which is an unsigned long on ARM64 and
> is often assigned to an int (int32) in the Cocoa lib.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
