You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rust count returns usize; rather than (potentially down-)casting to uint32_t, does it make sense to change the example to return size_t? And then you don't need a cast.
In the C code, the printf format should be %u, or %zu if you use size_t. (Also you'll want to use %u in /slice_arguments/, and in /tuples. Or use int32_t, for which %d is appropriate.)
The text was updated successfully, but these errors were encountered:
The second part of this has been addressed in #76. About returning a count usize, it sounds reasonable, since it's heavily related to the size of some object in memory. But I wouldn't find either one particularly incorrect either, as long as the output is sure not to overflow a uint32_t. Maybe this is just a decision to be made on a case-by-case basis, depending on whether you wish to abstract away from the (potentially awkward) definition of size_t. There would be cases where this is unambiguous, of course: if the library was providing the number of views on a YouTube video, we'd totally go for a uint64_t instead.
Re: http://jakegoulding.com/rust-ffi-omnibus/string_arguments/
Rust
count
returnsusize
; rather than (potentially down-)casting to uint32_t, does it make sense to change the example to returnsize_t
? And then you don't need a cast.In the C code, the
printf
format should be%u
, or%zu
if you usesize_t
. (Also you'll want to use%u
in /slice_arguments/, and in /tuples. Or useint32_t
, for which%d
is appropriate.)The text was updated successfully, but these errors were encountered: