Silence aggressive int/uint compiler warnings and align API with Core Audio

[mman]

This PR makes the TPCurcularBuffer API compatible with Core Audio by using UInt32 instead of int for all fields that are interfacing with Core Audio. It also uses uint32_t instead of int for fields that are supposed to be positive only. As a side effect this change silences aggressive C compiler warnings about comparison, conversion, and assignment of signed/unsigned int values.

Tested on iOS/macOS project(s) under XCode 9.2.

[edwin-oetelaar]

Is there a reason to use 2 types of unsigned int32 ? (UInt32 and uint32_t) Would using uint32_t (the standard) not silence you compiler warnings? I do not own a Mac, I do linux, never seen UInt32 anywhere (strange capitalisation for a 'C' type anyway)

[mman]

@edwin-oetelaar The low level functions defined by Michael use plain C uint32_t and int32_t to make the code super portable and relying only on low level BSD calls.

The iOS/Mac Core Audio API uses UInt32 for many fields and I therefore chose to go that way for iOS/Mac specific code. We can definitely make a case that uint32_t is more standard and more or less synonym for UInt32 but in this case I deliberately chose to use the same data type as Code Audio as a convenience and to help developers understand.

[michaeltyson]

Lovely! I’ve been meaning to do this for a while, thanks! Yep, I agree with your use of UInt32 rather then uint32_t for the Core Audio specific functions

[mman]

Thanks Michael :)