shared/json: use int64_t instead of intmax_t

We were already asserting that the intmax_t and uintmax_t types
are the same as int64_t and uint64_t. Pretty much everywhere in
the code base we use the latter types. In principle intmax_t could
be something different on some new architecture, and then the code would
fail to compile or behave differently. We actually do not want the code
to behave differently on those architectures, because that'd break
interoperability. So let's just use int64_t/uint64_t since that's what
we indend to use.
This commit is contained in:
Zbigniew Jędrzejewski-Szmek
2021-11-18 01:34:31 +01:00
parent a810dd5c00
commit 718ca77232
15 changed files with 113 additions and 121 deletions
@@ -200,7 +200,7 @@ _public_ int cryptsetup_token_validate(
}
JSON_VARIANT_ARRAY_FOREACH(e, w) {
uintmax_t u;
uint64_t u;
if (!json_variant_is_number(e)) {
crypt_log_debug(cd, "TPM2 PCR is not a number.");
@@ -78,7 +78,7 @@ int parse_luks2_tpm2_data(
return -EINVAL;
JSON_VARIANT_ARRAY_FOREACH(e, w) {
uintmax_t u;
uint64_t u;
if (!json_variant_is_number(e))
return -EINVAL;
+1 -1
View File
@@ -116,7 +116,7 @@ int find_tpm2_auto_data(
assert(pcr_mask == 0);
JSON_VARIANT_ARRAY_FOREACH(e, w) {
uintmax_t u;
uint64_t u;
if (!json_variant_is_number(e))
return log_error_errno(SYNTHETIC_ERRNO(EINVAL),