why does the int_value of the pa_json_object structure need to be declared as int64_t?

[Arun Raghavan]

On Tue, 9 Jul 2024, at 7:22 AM, 赵成义 wrote:
> Hi Arun,
>
>>Can I change "int64_t int_value;" to "int int_value;"?
>>In the ./src/pulse/format.c file, the function pa_json_object_get_int
>>is called multiple times, converting int64_t to int.
>
>>./src/pulse/format.c:
>>
>>int pa_format_info_get_prop_int(const pa_format_info *f, const char *key, int *v) {
>>  const char *str;
>>  pa_json_object *o;
>>
>>  pa_assert(f);
>>  pa_assert(key);
>>  pa_assert(v);
>>
>>  str = pa_proplist_gets(f->plist, key);
>>  if (!str)
>>      return -PA_ERR_NOENTITY;
>>
>>  o = pa_json_parse(str);
>>  if (!o) {
>>      pa_log_debug("Failed to parse format info property '%s'.", key);
>>      return -PA_ERR_INVALID;
>>  }
>>
>>  if (pa_json_object_get_type(o) != PA_JSON_TYPE_INT) {
>>      pa_log_debug("Format info property '%s' type is not int.", key);
>>      pa_json_object_free(o);
>>      return -PA_ERR_INVALID;
>>  }
>>
>>  *v = pa_json_object_get_int(o);
>
> I just want to avoid truncation or overflow errors caused by implicit 
> type conversion from int64_t to int here.
> If you think there is no problem with the conversion here, I will not 
> modify it.

Well, for reasons I don't recall, I made the pa_format_info work with int rather than int64_t. In practice, since we're mostly dealing with channel count and sampling rate, there will not be any truncation etc. on 32-bit platforms.

We can't change this as it's public API now, but we could add a int64 getter instead if there's a case for it.

-- Arun