Re: [PATCH 10/17] compat/rust_types.h: define rust primitive types

[Junio C Hamano <gitster@pobox.com>]

"Ezekiel Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> +/*
> + * A typedef for bool is not needed because C bool and Rust bool are
> + * the same if #include <stdbool.h> is used.
> + */
> +
> +typedef uint8_t   u8;
> +typedef uint16_t  u16;
> +typedef uint32_t  u32;
> +typedef uint64_t  u64;
> +
> +typedef int8_t    i8;
> +typedef int16_t   i16;
> +typedef int32_t   i32;
> +typedef int64_t   i64;

The standard guarantees that these are all of the above are exactly
N-bits wide, so I can buy the above types.  But before I can buy the
above typedefs, don't we need to rename existing variables that
squat on these names?

    $ git grep -n -E -e '\<[ui](8|16|32|64)\>'

gives some hits, like

    reftable/record.c:678:	uint8_t i64[8];
    t/helper/test-parse-options.c:123:	uint16_t u16 = 0;
    t/helper/test-parse-options.c:148:		OPT_UNSIGNED(0, "u16", &u16, "get a 16 bit unsigned integer"),

to avoid confusion?  There are handful other hits.

> +typedef float     f32;
> +typedef double    f64;

It may be that they can be used interchangeably in practice on
popular platforms, but are these guaranteed to be equivalent by some
standard?  C only cares about the minimum required range and
precision, so you may have allocated enough bytes thinking you can
fit a f32 but your float may not fit there.

Or does Rust care only about platforms with IEEE 754 and would
refuse to port to other exotic architectures so the above worries
would not apply?

> +typedef size_t    usize;
> +typedef ptrdiff_t isize;

Interesting.  I would have expected, "isize" that is a signed
variant of "usize" to be aliased out of ssize_t (simply because it
is declared that "usize" corresponds to "size_t" on the previous
line), not using ptrdiff_t.

> +typedef uint32_t  rust_char;
> +
> +#endif /* COMPAT_RUST_TYPES_H */