Obj-C SDK: negative sint32 developer field values return 0

In the Obj-C SDK, FITDeveloperField.getValueFor(0) returns 0 for developer fields with base type sint32 (0x85 / 133) when the value is negative. Positive sint32 values decode correctly on the exact same code path. Java SDK (via FIT CSV Tool and fitfileviewer.com) reads the same files correctly, including negatives.

Same field name (calibration on device_info), same base type, same SDK build — only the sign differs.

Reading code (called from a MesgListener):

SWIFT EXAMPLE
let name = devField.definition.getFieldNameforIndex(0)
let rawNumber = devField.getValueFor(0)
let baseType = devField.definition.getFitBaseTypeId()
print("name:\(name ?? "nil") rawNSNumber:\(rawNumber) baseType:\(baseType)")

Output:

// File with negative values on disk (e.g. -45 per Java SDK):
dev field — name:calibration  rawNSNumber:0  baseType:133
dev field — name:calibration  rawNSNumber:0  baseType:133

// File with positive values:
dev field — name:calibration  rawNSNumber:108  baseType:133
dev field — name:calibration  rawNSNumber:107  baseType:133

Looks like the sint32 path isn't sign-extending — values with the sign bit set get clamped to 0 instead of returned as negative. Worth checking sint8/sint16/sint64 too.

Happy to share test files. Thanks!

  • The Objective-C SDK is a wrapper around the C++SDK. The C++ SDKs rely on the overflow behavior of the compiler to wrap instead of clamp. I am not sure if the clamping is happening in Clang or the LLVM or if there is a compiler option that can change this behavior. This is the first report of this in four years, so we have not spent anytime on a fix. The "fix" is to use the Swift SDK, see my reply to your other question about that SDK.