я не восхвалял. Я вам доказал, что оптимизированный код изменён до полной неузнаваемости. Если ваш код на 146% соответствует стандарту, то он будет работать точно также по результату, иначе — как карта ляжет. Причём ошибка может таится в самом неожиданном месте.

ну вот вам пример: http://blog.llvm.org/2011/05/what-every … ow_14.html

void contains_null_check(int *P) {
  int dead = *P;
  if (P == 0)
    return;
  *P = 4;
}

компилятор _может_ превратить в

void contains_null_check_after_RNCE_and_DCE(int *P) {
  *P = 4;
}

А может и не превратить. Зависит от фазы луны.

А всего-то была проблема в том, что в данном коде разименовывается указатель P. Причём результат ни на что не влияет, т.к. переменная dead НЕ используется. На первый взгляд: ну и что? На второй: а действительно, что?
Фишка в том, что разименованный NULL, это UB. А UB это вовсе не "непонятный результат", всё намного хуже, это неопределённое ДЕЙСТВИЕ. Т.е. компилятор в данном случае, по стандарту(sic!) может рожать любой код. Ну при -O3 он естественно ничего не рожает, ибо "ничего" самое быстрое. Проблема в том, что это "ничего" намного сильнее, чем вы думаете, ВНЕЗАПНО, компилятор не только ничего не делает для разименования, но и считает, что само разименование невозможно! (имеет право, да). А значит, P ВСЕГДА НЕ NULL! А раз так, то и проверка не нужна.

ну вы же делаете…

где? Не в убунте, а в астре? Дык там и так ВР.

дык давайте бинарник, чего вы боитесь-то? Можете мне лично отправить на emulek.bx@gmail.com

это совершенно другая тема. Ну и вы опять не проверяли ещё хотя-бы на десяти дистрибутивах. Да и в проблеме не разобрались.

значит это глюк glibc. Давайте проверим на моей, ванильной версии. Если на ванили заработает, значит действительно, патч убунты испортил glibc. Пошлём багрепорт, и они быстренько исправят.

А нытьём и разговорами мы ничего не добьёмся.

Так меньше никак не должно быть, только больше.
Но в Debian Wheezy выдерживается точно.

Пётр.

Нет, такого я не делаю.

И в Ubuntu обе по 16 байтов.

Отправил. По-прежнему с gettimeofday() sendto() заканчивается с ошибкой 22, без неё работает.
Наверное, это чьи-то козни.

Пётр.

Peter, ну вы мне вторую часть вышлите, а то первая часть просто висит, и ждёт.

код лень ковырять, там Ад и Израиль.

у вас очень зависимый код. Такой блоб из одной функции, где всё друг за друга цепляется. Компилятор пытается это всё по регистрам распихать, получается ещё хуже, т.к. вы обожаете отправлять куски памяти в стандартные функции. Но всё равно компилятор распихивает данные и в память и в регистры, причём регистров в amd64 довольно много разных.

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

я же говорю: адский клубок и переплетение памяти, регистров, и т.п. Чёрт ногу сломит. Код ужасен.

ЗЫЖ отправьте пожалуйста ещё и рабочий вариант, попробую найти разницу, если это конечно возможно.

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

Пётр.

Совершенно не вижу в этом проблемы. Несколько байтов или несколько их десятков не жалко, а так единообразнее.
И вообще обычный C требует, чтобы объявления располагались до исполнимых операторов.

Пётр.

Ну мало где что написано. Сейчас нет надобности бороться за каждую ячейку памяти, а мне удобнее, чтобы все объявления были в одном месте.
Вчера я в Debian искал, где определяется size_t, в прямом виде не нашёл. size_type вроде бы unsigned int.
Глобальных переменных я по возможности избегаю, но, если переменная требуется во многих подпрограммах в одном модуле,
то всё же удобнее сделать её глобальной.

Пётр.

Представьте себе, читал про static. Но без особой надобности я об этом не беспокоюсь.
Например, у меня редко бывает так, чтобы переменная из одного модуля была видна в другом.

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

Пётр.

Для этого ещё нужен extern. А в присланных мною программах все переменные локальные.

Если тип не устраивает компилятор, то об этом будет сообщение. А если сообщения нет, значит, компилятор сам привёл
аргументы к требуемому типу. Например, число.

Само собой ничего не бывает. Если они попортятся, то только из-за ошибки, тогда она будет замечена и исправлена.

Насчёт регистров не моё дело. Если же с -O3 программа работает неправильно, то это опять же следствие ошибки
и она будет выявлена и исправлена.

Вот вы уже три страницы меня обличаете и даже, можно сказать, окатывате ушатами, а ошибку в присланной imit_cam.c
так и не нашли, хотя и напрягали всю силу своей мысли. Наверное, тут нужен Шерлок Холмс.

Пётр.

Я же сказал, что и g++ скомпилировал это без сообщений.
рп
Таж же только main, других модулей и подпрограмм нет, какие могут быть проблемы хоть с переменными,
хоть с указателями? Пока программа работает, указатель остаётся актуальным. Например, в реальной
программе на Qt, с которой может связываться этот imit_cam.c, указатели на массивы передаются из
одного потока в другой и всё это работает без сбоев.

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

Я удивляюсь, как можно относиться с неприязнью к C. Это удобный и естественный язык, не случайно ведь
именно на нём написана Linux.

Код простой, и у вас же вариант с отступами. Там всего три вызова функций, последний в цикле.
Ничего сложного там нет, всё построено из найдённых примеров. Наверное, это всё же порок Ubuntu,
в ней вон и QTimer интервалы выдерживает неточно.

Пётр.

void* для этого и предназначен.
Конечно, я бы не стал пытаться вместо double передавать int, но вместо переменной типа double можно подставить число этого же типа.
Конечно, Ubuntu, иначе как объяснить, что в ней в Qt timeout таймера вместо 4000 миллисекунд составляет 4063?
А в Debian в пределах гранулированности.
Сдаётся мне, что вы руководствуетесь тем фактом, что "метода военная действие наступательное всегда действию оборонительному
предпочитает", вот вы и стараетесь сбить меня с одних позиций, будучи не в силах взять другие.
Т.е. я так и не уловил, почему в Ubuntu наличие gettimeofday() в тексте влияет на прдшествующую её вызову sendto().

Пётр.

Конкретных ошибок вы не назвали. Возможно, их там и нет, иначе вы бы их сразу заметили.
Однако, если успею, попробую уточнить ситуацию.

Пётр.