Это мысленный эксперимент, а не производственный код или хороший стиль кодирования.
Предположим, что эта функция
int find_process_pid_by_name(char* name, int* threads_in_process);
которые возвращают PID именованного процесса, а также всегда сохраняют в threads_in_process количество потоков, выполняющихся в указанном процессе.
ленивый программист, интересующийся только PID, пишет этот код
int pid = find_process_pid_by_name("a process name", &pid);
Вызывает ли это поведение undefined?
Нет - я не думаю, что это поведение undefined. Там есть точка последовательности непосредственно перед вызовом функции (после того, как были оценены аргументы и выражение, которое обозначает вызываемую функцию), а там еще до того, как вызываемая функция вернется. Любые побочные эффекты на pid, выполняемые вызываемой функцией, были завершены до того, как функция завершит возврат. Затем результат функции присваивается pid. Там нет вопроса о местоположении, которое назначается для изменения функции. Я не вижу ничего, что вызывает поведение undefined.
Я предполагаю, что вызываемая функция рассматривает аргумент int * как указатель на запись только для одного значения. Если он читает из одного значения, нам нужно знать, что pid был ранее инициализирован (формально, на практике это не имеет значения). В контексте pid не был инициализирован; результат функции будет инициализирован. Итак, если функция читает из аргумента указателя, технически вы имеете поведение undefined. Если функция обрабатывает указатель как начало многоэлементного массива и выходит за пределы нулевого элемента, возникают проблемы. Но эти вопросы несколько выходят за рамки предполагаемого объема вопроса/обсуждения.
Да, я считаю, что этот код хорошо определен. В конце функции есть точка последовательности до того, как возвращаемое значение будет скопировано в вызывающий контекст. Таким образом, функция сначала будет назначаться pid косвенно через threads_in_process, затем она вернется, а затем возвращаемое значение будет присвоено pid.