touchHLE icon indicating copy to clipboard operation
touchHLE copied to clipboard

Type aliases for C types

Open hikari-no-yume opened this issue 2 years ago • 1 comments

Currently we have Rust types or type aliases for pointers (Ptr, …), sizes (GuestUSize, GuestISize), key Objective-C types (id, SEL, …), Foundation types (NSInteger, …), and more, but the core C integer and float types don't have aliases. Instead, a specific Rust type is usually written. The current practice is:

  • char variants used for character data are usually mapped to u8, regardless of their actual sign (TODO: check what sign normal char has on iPhone OS), because Rust uses u8 for byte strings
  • Other uses of char are u8 or i8 as appropriate.
  • Not sure if short ever gets used, but that would be i16.
  • int, long => i32
  • unsigned, unsigned long => u32
  • long long => i64
  • unsigned long long => u64
  • float => f32
  • double => f64

Ignoring char, these types are perfectly correct for 32-bit ARM iPhone OS/iOS apps, but they might prevent us from supporting other architectures in the future: 64-bit ARM, 32-bit or 64-bit x86 (Simulator ABI), etc. Of course it's unlikely any of these will ever be supported. The main thing that bothers me is it's a loss of information in type signatures. It also requires contributors to correctly remember what particular types map to in the ABI, which I'm sure will go wrong at some point.

The only problem is: how would we name the aliases, and where would we put them? I don't want to use names like c_int because that clashes with Rust's own type aliases. I also think GuestInt might be a bit verbose, though that is consistent. Maybe gc_int? Though that maybe sounds too much like “garbage collection”.

hikari-no-yume avatar Feb 10 '23 14:02 hikari-no-yume

https://developer.apple.com/documentation/xcode/writing-armv6-code-for-ios#Handle-data-types-and-data-alignment-properly is a nice reference for type sizes.

hikari-no-yume avatar Nov 05 '23 22:11 hikari-no-yume