> тут я с Вами не соглашусь - тут и анализ завершения и анализ наличия ошибкиой, да какого хрена разница. Если вернуться в начало, то вообще исходно разговор начался с того, что rust бы спас от этой проблемы. А то к чему мы пришли -- это спор о смыслах слов. Был программерский спор, стал лингвистический. То есть, мы залезли в оффтоп.
Возвращаясь же к исходному вопросу: я не знаю, спас бы раст от этой проблемы или нет. Покажите мне, как на rust'е это делать, и тогда можно будет судить. Тот API который есть просто нежизнеспособен с растом, потому как там два вызова выше, которые принимают data как &mut ссылку, и где-то там хранят две mut ссылки на неё. Это ноно, нини, никак нельзя. В смысле и в C не стоит так делать, а если всё же делаешь, то надо ОЧЕНЬ сильно подумать, и потратить не менее получаса на поиск граблей, на которые можно наступить при этом. Но в rust'е это сильнее нельзя, потому что без unsafe'а сделать не удастся, а с unsafe'ом оно конечно можно, в смысле это могут принять другие, но только ежели unsafety не пересекает границ модуля. Здесь он пересекает. То есть g_dbus_connection_call должен быть unsafe вызовом (это лишь _соглашение_ растоманов, но они всё же следят за ним когда читают или пишут код). Ну а если мы начинаем использовать unsafe API, то гарантии раста, как бэ, подвисают в воздухе.
> По поводу данных - там выше есть функция on_retrieved_unix_uid_pid()
Которая, судя по её коду, заточена под то, что она будет вызвана дважды. На каждый асинхронный вызов она вызывает g_connection_call_finish. И что-то пишет в data, вне зависимости от того, как там сыграют ветки if'ов: она просто в разные места data пишет, в зависимости от if'ов. Если между этими двумя вызовами коллбека произойдёт return в polkit_system_bus_name_get_creds_sync, то второй вызов будет писать в удалённый стековый фрейм.
edit:
> делает какой-то single iteration судя по документации
А, вот это похоже на правду. Надо полагать, что dangling указателя, всё же не возникает.
