Есть такой кусок кода:(вернее, много подобных вариантов)
ewavr5 (впрочем и 4 тоже) выдает варнинг:
Warning[Pa079]: undefined behavior: variable "iBufIndex" (or a value reached by some form of indirection through it) is modified more than once without an intervening sequence point in this
Насколько я понимаю, ему не нравится то, что переменная меняется несколько раз. Если сделать так:ругаться перестает. Второй вариант мне не особо нравится, потому что тут нужно отслеживать величину изменения индекса. Можно ли как-то избавиться от этих варнингов не используя второй вариант кода? или на них просто стоит забить?

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

Второй ваш вариант правильный. Использование первого может привести к непредсказуемым глюкам. Так что компилятор вас предупреждает совершенно обоснованно.
P.S. а почему нельзя передавать в функцию сразу значения?

vet абсолютно прав, за исключением того, что "вызов RestoreChar правильно" - будет в обоих случаях. Порядок вычисления аргументов может зависить от чего угодно, вплоть до расположения звезд (точнее, от алгоритма оптимизатора, но это примерно эквивалентно ). Если вам не нравится первый вариант - заведите две временных переменных и присвойте им значения одновременно с увеличением индекса. Если таких мест много, можно все это обернуть в #define (args) do { .... } while(0). Если эта программа портирована с какого-то компилятора, и тот компилятор не выдавал подобного предупреждения - он был сильно не прав.

да, это я неточно сформулировал мысль; подразумевалось, что, если RxBufU0[]={...,11,22,...}, то упомянутый вызов может произойти как с аргументами (11,22), так и с (22,11), в зависимости от того, инкремент индекса какого параметра произошел раньше.

Угу. Я это же и имел в виду. Зачем закладывать мину там, где можно обойтись без нее? Не нужно лениться две-три, на первый взгляд "лишних", операции написать. Компилятор все равно оптимизирует примерно в тот же самый код, что и "до того как", но зато неопределенность будет устранена.

Двойной инкримент в одном операторе никогда не станет стандартом С.