cleanup: Add typedefs for public API int identifiers.

[iphydf]

These make it clearer which kinds of uint32_t can fit in which functions. It also makes it easier to generate higher level bindings without doing a lot of inference/heuristics.

---

This change is 

[codecov]

Codecov Report

Attention: 6 lines in your changes are missing coverage. Please review.

Comparison is base (cac074c) 68.96% compared to head (79f55bd) 68.98%.

Files	Patch %	Lines
toxcore/tox.c	73.91%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2518      +/-   ##
==========================================
+ Coverage   68.96%   68.98%   +0.01%     
==========================================
  Files          89       89              
  Lines       27781    27781              
==========================================
+ Hits        19160    19165       +5     
+ Misses       8621     8616       -5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[nurupo]

Eh, an alias? That's somewhat useless, isn't it? One can still just pass uint32_t for it. I guess it does serve a documentive purpose... But why not just make them structs at that point, so that each are a unique type of their own, instead of just an alias? Could even be an opaque struct instead of a struct of uint32_t. The client code shouldn't rely on the values of those uint32_ts anyway. That would break both API and ABI though, so I guess that would be one reason not to do it.

[iphydf]

Eh, an alias? That's somewhat useless, isn't it? One can still just pass uint32_t for it. I guess it does serve a documentive purpose... But why not just make them structs at that point, so that each are a unique type of their own, instead of just an alias? Could even be an opaque struct instead of a struct of uint32_t. The client code shouldn't rely on the values of those uint32_ts anyway. That would break both API and ABI though, so I guess that would be one reason not to do it.

The point is to show which uint32_t goes where. Sure, the client won't do anything to them, but they might pass a friend number where a peer number is required. This makes that a bit clearer from the function signature. Structs would break the API (not the ABI), so I don't want to do that in 0.2.x.

[nurupo]

Structs would break the API (not the ABI)

Correct, non-opaque structs wouldn't break the ABI. A struct of uint32_t should have the same ABI as just uint32_t. However, opaque structs -- a pointer to a struct, e.g. for Friend Number (would have to be renamed to Friend Handle since it's no longer a number?) would break the ABI. 32-bit uint32_t vs 64-bit/platform-dependent-size pointer to a struct. But you already know all that better than I do :P

[nurupo]

This is a big improvement.

Personally I would prefer to go even further with this and use distinct types, e.g. structs and even opaque structs in cases where uint32_t is an internal implementation detail that user isn't supposed to use for anything, but this non-breaking change is fine too. Maybe sometime in the future.

CI is complaining that function declarations in tox.c weren't updated to use arrays, they still use pointers. Other than that - LGTM.

Reviewed 1 of 1 files at r2, 1 of 1 files at r4.
Reviewable status: complete! 1 of 1 approvals obtained

[nurupo]

CI is complaining that function declarations in tox.c weren't updated to use arrays, they still use pointers. Other than that - LGTM.

Ah, looks like that was already fixed while I was away.