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
