Теперь (и только теперь) можно заняться и оптимизацией.

зачем? Всё и так работает.
рефакторинг разве-то поможет.

я и не господь б-г.  Могу и заблуждаться. Просветите, буду благодарен.

Возможно, их там и нет, иначе вы бы их сразу заметили.

я сразу заметил, в посте №8.

потому что инициализацию надо делать непосредственно перед использованием. Лучше и объявление тоже. Тогда такие ошибки сразу видно.

Пётр.

Пётр.

Пётр.

void* для этого и предназначен.

угу. Потому что без void* невозможно создать полиморфную функцию. А с void* можно, но никто не может гарантировать правильность типа. Т.е. правильность работы держится буквально на честном слове. Да, вы торжественно обещаете, что будете всё делать по правилам. Но не делаете.

я без понятия. Это проблема Qt, при чём тут Ubuntu?

да, ситуация патовая: я вам указал ошибки, но вы их исправлять не желаете, мотивируя это тем, что дескать "мой быдлокод в некоторых случаях работает как надо".

Я вот не понимаю, почему нельзя перед sendto сделать отладочную печать, выводя все параметры в удобочитаемом виде? Ну раз оно пишет EINVAL, значит параметры испорчены, так? Вот и узнаем, КАКОЙ параметр испорчен. Либо докажем, что у нас всё хорошо, а быдлокодеры Марка испортили няшную glibc.

//fixed

Пётр.

Я же сказал, что и g++ скомпилировал это без сообщений.
рп

я же сказал, что отсутствие сообщений ни о чём не говорит.

В сишке к сожалению всего один самый тупой static_cast, который указатели в x86 совершенно тупо кастует, причём ошибок не пишет, даже если кастовать (тёплое*) в (мягкое*).

А специальный тип void* так вообще во что угодно неявно кастуется.

важно.

просто вы ещё с UB не сталкивались.

угу. Напомнило "во всём виновата Windows".

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

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

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

Пётр.

Для этого ещё нужен extern.

угу. Нужен.

проблема указателей в том, что они ВСЕГДА глобальные. И если у вас что-то возвращает/принимает указатель, то эта переменная всё равно видится где угодно. Даже если она и "локальная".

не правильно. Компилятор сам конечно переведёт, но проверять компилятор ничего не будет, полагается, что программист сам знает, что делает. В сишке можно что угодно перевести во что угодно, и никаких сообщений это не вызовет. Сообщения возникают лишь если компилятор в принципе не может что-то перевести. А если может, то как в ассемблере: есть просто тупо адрес, и тупо ВСЁ. Причём никого не волнует, если у вас ошибка, компилятор ничего проверять не будет.

в сишке с UB — на каждом шагу.
Именно потому, многие люто, бешено ненавидят сишку.

исправляйте.

в вашем коде копаться — дело не очень приятное.

Peter пишет:

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

у вас так ВСЕГДА, потому что "не беспокоитесь".

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

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

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

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

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

Пётр.

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

у вас так ВСЕГДА, потому что "не беспокоитесь".

ну во первых вы тип не можете задать нормально. Проблема как раз в том и заключается, что UB может как угодно и когда угодно проявиться. А может и НЕ проявится.

есть Over9000 причин для этого.

ещё они в регистрах лежат, не только в памяти. И не факт, что эти регистры сохраняются во время сисколлов. Может сискол делает pusha, но 32х битную версию по недосмотру? А может и не делает. Кто знает? В amd64 множество "лишних" регистров, которых не было в IA-32, потому старый код про них не в курсе, и возможно их не сохраняет. Этот старый код может вызывать более новый код в ядре, который новые регистры использует. Может сам компилятор запутался, и что-то не так соптимизировал (кстати, с -O3 это бывает).

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

Пётр.

Сейчас нет надобности бороться за каждую ячейку памяти

facepalm

Да при чём тут экономия?! 

Речь о совместимости и о надёжности.

Вам на это наплевать, потому ваш код тут работает, а там не работает.

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

зачем? Всё что вам нужно знать о size_t, то только то, что размер size_t достаточный для сохранения длинны _любого_ объекта в памяти. Всё. Сколько оно на самом деле — не имеет никакого значения, и ваш код обязан работать даже если size_t это char, и не бывает размера больше 127 байтов.

Для интерфейса с сокетами size_t не подходит, там свой стандарт, потому определён специальный тип socklen_t. И да, каст int ←→ size_t/socklen_t в общем случае UB, т.е. если ваш код отформатирует ваш HDD, в этом не будет ничего удивительного.

почитайте хотя бы про static.  Если "в одном модуле".