Странность с va_copy

[vitus_wagner]

Вот такую странную картину я тут наблюдаю:

Debian testing, gcc 8.2.0. Имеется вот такой C-шный код:

static void log (int elevel,  const char *fmt, va_list args)
{
 bool write_to_file, write_to_stderr, write_somewhere_else;
 va_list error_args, std_args;
.... здесь вычисляем куда надо писать
if (write_to_file && write_to_stderr) 
  va_copy(std_args,args);

.... некоторое количество кода, заведомо не меняющего флагов write_to
if (write_to_file) {
   vfprintf(f,fmt, args);
}
if (write_to_stderr) {
   if (write_to_file) {
      vfprintf(stderr, fmt, std_args);
   } else {
      vfprintf(stderr,fmt,args);
   }
   ffush(stderr);
}

В 64-битной системе компилятор кушает этот код без вопросов. В 32-битной ругается

error: ‘std_args’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
vfprintf(stderr, fmt, std_args);

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

Comments

[livelight]

Это компилятору надо догадаться, что условие

if (write_to_stderr) {
   if (write_to_file) {

эквивалентно условию

if (write_to_file && write_to_stderr)

А это, кроме всего прочего, ещё и другой порядок аргументов в короткой конъюнкции.

[vitus_wagner]

Ну тот же компилятор на 64-битной архитектуре догадывается как-то. И все остальные компиляторы на 64-битной архитектуре догадываются.

А у меня их там мно-о-ого - от GCC 4.3.4 в SUSE 11 до этого самого 8.2 и еще некоторое количество CLANG-ов.

[livelight]

Я бы на месте даже не компиляторов, а программистов, ругался во всех архитектурах. Даже после понимания про тождественность логических условий. Ибо что такое этот va_copy? Ну, допустим, в какой-то архитектуре повезло, и это явное копирование. Но я бы на всякий случай предполагал, что это, как и в большинстве Си-шных конструкци такого рода, - просто вызов некой функции, которой передают указатели на оба аргумента. Однако, передача в какую-то функцию указателя на локальную переменную - ещё не повод считать эту переменную инициализированной.

[vitus_wagner]

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

Вообще, gcc в режиме проверок умеет много разных гитик. Например умеет понимать конструкцию вида

switch(v) {
case SOMETHING:
      some code
      /* Fall THRU*/
case SOMETHING_ELSE:
      some other code
      break;
case default:

}

и не ругаться на отсутствие break в первом случае.

[livelight]

Я даже как-то писал код без break перед default.
Но по-хорошему, конечно, надо там вместо брейка ставить какую-то конструкцию, однозначно понимаемую и человеком, и компилятором, что брейк здесь пропущен умышленно. Вроде, в C# так и сделали.

[vitus_wagner]

Ну вот комментарий /* Fall THRU */ там и стоит. Его небось еще в 70-е годы в lint поддерживали.

[livelight]

Именно в таком виде я его не видел ни разу (видел только примерно такой, с точностью до регистра), так что не уверен в степени его стандартности и общепризнанности.

[qwe_rty]

Компилятор не обязан заниматься условным протаскиванием присваиваний. Никакой стандарт от него этого не требует, хотя и не запрещает заниматься какими угодно оптимизациями. Правильно было бы вынести va_copy из-под условия. Если компилятор умный, он убъет это присваивание как мертвый код.

[vitus_wagner]

Компилятор именно этим и обязан заниматься, если он берется выдавать warning-и о возможно неициализированных переменных,

[livelight]

Ну он же сказал: возможно неинициализированная. Ну недопёр, бывает. Он обязан, конечно, но, как строго доказано, на любой умный компилятор можно найти текст программы, в котором он некоторые свойства не сможет распознать.
А бывают ещё случаи, когда переменная заведомо неинициализированная.

[vitus_wagner]

У нас вроде не тот случай. Хотя случай с openssl где неинициализированную память добавляли к пулу энтропии, а потом в debian это попытались отломать, все помнят.

[qwe_rty]

Ничего подобного. Это сообщение означает, что переменная, возможно, не инициализирована, а не что она обязательно не инициализирована. В общем случае к другому не сводимо. Из современных компиляторов немногие протягивают присваивания условно. Это непросто.

[qwe_rty]

Вообще, компилятор обязан заниматься только тем, что указано в стандарте языка. Хороший компилятор, конечно, обычно делает больше. У разных компиляторов это больше разное, к тому же меняется версия от версии. В данном случае правильно было бы вынести вызов va_copy из-под условия. Компилятор перестанет ругаться, исходники станут проще, порожденный код вряд ли станет длиннее или медленнее, скорее наоборот.

[qkowlew]

Может быть разница в реализации макросов.
У меня было как-то ещё в эпоху PDP-11 и "Ленинградского Си" анекдотическое.

if (условие) функция();

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

if (условие) { функция(); }

компилировалось как ожидалось и работало правильно.

[vitus_wagner]

Ну да, а все эта фигня вокруг varargs (теперь stdargs) она как раз на махровых макросах и сделана.

[vitus_wagner]

Посмотрел выдачу препроцессора. Хрен там. Раскрвыается va_copy просто в __builtin_va_copy.
А vfprintf вообще не макрос.

Еще интереснее - результат препроцессирования данной функции в 32-битной среде (где ругается) и в 64-битной) вообще никак не различается.

[livelight]

А вот тех, кто пишет такой развесистый макрос, не окружив его собственными скобками соответствующей формы, надо бить канделябрами.

[vitus_wagner]

Скобки нифига не помогают.


И макрос не такой уж развесистый.

[livelight]

Раз ручное окружение вызова макроса фигурными скобками помогает - значит, макрос обязан сам в себя включать эти фигурные скобки, чтобы гарантированно сохранять синтаксическую целостность своего тела.

К счастью, конфликтов, когда в одних контекстах надо бы окружать фигурными скобками, а в других - круглыми, в Си не бывает. По крайней мере, я таких примеров не встречал.

[vitus_wagner]

Это в куковлевском случае помогает. В моем - не помогает.

[livelight]

А ещё в куковлевском примере с финальным ";" могут быть проблемы, если после if с макросом идёт else. Вот эта болезнь языка препроцессора не имеет хорошего лекарства, кроме опять же ручного окружения if-блока и else-блока в собственные фигурные скобки.

Ну и вообще врождённых болезней у языка препроцессора много :)

[yurikhan]

Ну каноническое решение против else выглядит как

#define DO_SOMETHING(x) \
    do { \
        do_something_one(x); \
        do_something_two(x); \
    } while (0)

// …

if (condition)
    DO_SOMETHING(y);
else
    do_something_three(y);

[livelight]

Точно, было такое лекарство. Хотя назвать его "хорошим" язык не поворачивается :)

[yurikhan]

Ну, оно невкусное, да. В общем-то как и большинство лекарств.

[zevaka_derevnia]

Вот - только хотел написать. Старое и давно известное средство.

[qkowlew]

А наиболее вероятная архитектурная разница - в размерности указателей всё-таки.

Примерно как в Турбо Си 2.0 было две хорошо применяемых модели памяти - Tiny и Huge.

в первой указатели были 16-битные, и результат собирался в .com файл.
во второй указатели были кривые интеловские, но арифметика их РАБОТАЛА КОРРЕКТНО.

Попытки компилить РАБОТАЮЩИЙ в Tiny и Huge код в прочих моделях памяти (Small и Large) рано или поздно приводили к сегфолтам и к иным странным результатам.

[vitus_wagner]

Ну вот не понимаю, как в этом месте размерность указателей может на что-то повлиять.
Можно, конечно, залезть в определения макросов va_copy. Но лучше я это на авторов этого кода свалю.
У меня еще дохренадцать warning-ов в 12 ветках есть. (этот, правда, есть в 10 из 12).