Порядок оценки параметров перед вызовом функции в C

Нет, параметры функции не оцениваются в определенном порядке в C.

См. Ответы Мартина Йорка на вопрос What все ли распространенное неопределенное поведение, о котором должен знать программист на C ++?.

Порядок оценки аргументов функции не указан, из C99 §6.5.2.2p10:

Порядок оценки указателя функции, фактических аргументов и подвыражений внутри фактических аргументов не определен, но перед фактическим вызовом есть точка последовательности.

Аналогичная формулировка существует в C89.

Кроме того, вы изменяете pa несколько раз, не вмешиваясь в точки последовательности, что вызывает неопределенное поведение (оператор запятой вводит точку последовательности, а запятые, ограничивающие аргументы функции, нет). Если вы включите предупреждения на своем компиляторе, он должен вас предупредить об этом:

$ gcc -Wall -W -ansi -pedantic test.c -o test
test.c: In function ‘main’:
test.c:9: warning: operation on ‘pa’ may be undefined
test.c:9: warning: operation on ‘pa’ may be undefined
test.c:13: warning: operation on ‘pa’ may be undefined
test.c:13: warning: operation on ‘pa’ may be undefined
test.c:17: warning: operation on ‘pa’ may be undefined
test.c:17: warning: operation on ‘pa’ may be undefined
test.c:20: warning: control reaches end of non-void function

Просто чтобы добавить немного опыта.
Следующий код:

int i=1;
printf("%d %d %d\n", i++, i++, i);

приводит к

2 1 3 - использование g ++ 4.2.1 в Linux.i686
1 2 3 - использование SunStudio C ++ 5.9 в Linux. I686
2 1 3 - использование g ++ 4.2.1 в SunOS.x86pc
1 2 3 - использование SunStudio C ++ 5.9 в SunOS. x86pc
1 2 3 - использование g ++ 4.2.1 на SunOS.sun4u
1 2 3 - использование SunStudio C ++ 5.9 на SunOS.sun4u

Можно ли предположить порядок оценки параметров функции при ее вызове в C?

Нет, это невозможно предположить, если это неопределенное поведение, то проект стандарта C99 в разделе6.5 параграфа 3 говорится:

Группировка операторов и операндов обозначается синтаксисом.74) За исключением случаев, указанных ниже (для операторов вызова функции (), &&, ||,?: И запятой), порядок оценки подвыражений и порядок возникновения побочных эффектов не указан.

В нем также говорится, за исключением случаев, указанных ниже, и конкретно сайтов function-call (), поэтому мы видим, что позже в проекте стандарта в разделе 6.5.2.2 Вызов функций параграф 10 говорится:

Порядок оценки указателя функции, фактических аргументов и подвыражений внутри фактических аргументов не указан, но перед фактическим вызовом есть точка последовательности.

Эта программа также демонстрирует неопределенное поведение, поскольку вы изменяете pa более одного раза между точки последовательности. Из проекта стандарта раздела 6.5 абзаца 2:

Между предыдущей и следующей точкой следования значение объекта должно быть изменено не более одного раза путем оценки выражения. Кроме того, предыдущее значение должно быть прочитано только для определения значения, которое будет сохранено.

он цитирует следующие примеры кода как неопределенные:

i = ++i + 1;
a[i++] = i; 

Важно отметить, что хотя оператор запятой действительно вводит точки последовательности, запятая, используемая в вызовах функций, является разделитель, а не comma operator. Если мы посмотрим на раздел 6.5.17 оператор запятой, в абзаце 2 говорится:

Левый операнд оператора запятой оценивается как недействительное выражение; после его оценки есть точка следования.

но в параграфе 3 сказано:

ПРИМЕР Как указано в синтаксисе, оператор запятой (как описано в этом подпункте) не может появляться в контекстах, где запятая используется для разделения элементов в списке (например, аргументы функций или списки инициализаторов). .

Не зная этого, включение предупреждений с gcc с использованием хотя бы -Wall привело бы к появлению сообщения, аналогичного следующему:

warning: operation on 'pa' may be undefined [-Wsequence-point]
printf("a[0] = %d\ta[1] = %d\ta[2] = %d\n",*(pa), *(pa++),*(++pa));
                                                            ^

и по умолчанию clang выдаст предупреждение следующим сообщением:

warning: unsequenced modification and access to 'pa' [-Wunsequenced]
printf("a[0] = %d\ta[1] = %d\ta[2] = %d\n",*(pa), *(pa++),*(++pa));
                                            ~         ^

В общем, важно понимать, как использовать ваши инструменты наиболее эффективным образом, важно знать флаги, доступные для предупреждений, gcc вы можете найти эту информацию здесь. Некоторые полезные флаги, которые избавят вас от многих проблем в долгосрочной перспективе и являются общими для gcc и clang, - это -Wextra -Wconversion -pedantic. clang может оказаться очень полезным для понимания -fsanitize. Например, -fsanitize=undefined обнаружит множество экземпляров неопределенного поведения во время выполнения.

Как уже было сказано другими, порядок, в котором оцениваются аргументы функции, не указан, и между их оценкой нет точки последовательности. Поскольку вы впоследствии изменяете pa при передаче каждого аргумента, вы изменяете и читаете pa дважды между двумя точками последовательности. На самом деле это неопределенное поведение. Я нашел очень хорошее объяснение в руководстве GCC, которое, как мне кажется, может быть полезно:

Стандарты C и C ++ определяют порядок, в котором выражения в программе C / C ++ оцениваются с точки зрения точек последовательности, которые представляют частичный порядок между выполнением частей программы: те, которые выполняются до точки последовательности, и те, которые выполняются после Это. Это происходит после вычисления полного выражения (которое не является частью большего выражения), после вычисления первого операнда &&, ||,? : или, (запятая) перед вызовом функции (но после вычисления ее аргументов и выражения, обозначающего вызываемую функцию) и в некоторых других местах. За исключением случаев, указанных в правилах точки последовательности, порядок оценки подвыражений выражения не указывается. Все эти правила описывают только частичный порядок, а не полный порядок, поскольку, например, если две функции вызываются в одном выражении без точки последовательности между ними, порядок, в котором функции вызываются, не указывается. Однако комитет по стандартам постановил, что вызовы функций не перекрываются.

Не указано, когда вступают в силу изменения значений объектов между точками следования. Программы, поведение которых зависит от этого, имеют неопределенное поведение; стандарты C и C ++ указывают, что «Между предыдущей и следующей точкой последовательности объект должен иметь свое сохраненное значение, измененное не более одного раза при оценке выражения. Более того, предыдущее значение должно читаться только для определения значения, которое будет сохранено ». Если программа нарушает эти правила, результаты для любой конкретной реализации совершенно непредсказуемы.

Примеры кода с неопределенным поведением: a = a ++ ;, a [n] = b [n ++] и a [i ++] = i ;. Некоторые более сложные случаи не диагностируются с помощью этой опции, и она может давать случайные ложноположительные результаты, но в целом она оказалась достаточно эффективной для обнаружения такого рода проблем в программах.

Стандарт сформулирован запутанно, поэтому ведутся споры о точном значении правил точки последовательности в неуловимых случаях. Ссылки на обсуждение проблемы, включая предлагаемые формальные определения, можно найти на странице чтения GCC по адресу http://gcc.gnu.org/readings.html.

Изменение переменной в выражении более одного раза является неопределенным поведением. Таким образом, вы можете получить разные результаты на разных компиляторах. Поэтому избегайте изменения переменной более одного раза.

Ответ Гранта правильный, он не определен.

НО,,,

По вашему примеру, ваш компилятор, кажется, оценивает в порядке справа налево (неудивительно, что порядок, в котором аргументы помещаются в стек). Если вы можете провести другие тесты, чтобы показать, что порядок поддерживается последовательно даже при включенной оптимизации, и если вы собираетесь придерживаться только этой одной версии компилятора, вы можете смело предполагать порядок справа налево.

Это совершенно непереносимый и ужасный, ужасный поступок.