70-C9-4E-54-03-2F

В Си, да и в С++, стандартные целочисленные типы, поддерживаемые компилятором - это char, short, int, long long и их беззнаковые братья. Стандарт действительно не фиксирует размеры стандартных целочисленных типов. Это сделано потому что стандарт описывает абстрактный язык, который должен компилироваться для разных платформ.

Компилятор же компилирует программу под конкретную платформу с конкретными соглашениями по типам. Ему заведомо известны размеры стандартных типов на данной конкретной платформе. Стандартная библиотека так же обычно пишется под конкретный компилятор и конкретную платформу.
Так что (u)intX_t - это всегда define над стандартными типами. И ничего странного в этом нет.

Не претендую на глубокое знание плюсов, но...

Модификаторы типа вроде long или short не гарантируют увеличение или сокращение выделяемой памяти под переменную, а результат зависит от компилятора, - так пишется во многих учебниках. В то же время типы intx_t, описанные в библиотеке stdint.h, якобы гарантируют размер переменной.

Но ведь stdint.h идёт в комплекте с компилятором, а потому составлен с учётом особенностей этого компилятора.

В RouterOS DHCP-пакеты попадают в DHCP-клиент и в DHCP-сервер до попадания в IP Firewall, если речь идёт об IPv4.
Можно очень долго искать на форумах и в документации Mikrotik информацию про эту особенность, но не найти. Но выявляется эта особенность довольно легко на самом простом лабораторном стенде, что я и сделал во времена, когда только начинал администрировать оборудование Mikrotik.

Выбранный вами в качестве решения ответ Victor вводит в заблуждение - Bridge Filter и IP Firewall не связаны между собой. Просто в случае когда DHCP-сервер/клиент находится на Bridge-интерфейсе, то есть DHCP-трафик проходит через Bridge, то появляются два возможных варианта фильтровать DHCP-пакеты в Bridge:
1) использовать Bridge Filter для фильтрации
2) включить прохождение всего трафика Bridge через IP Firewall /interface bridge settings set use-ip-firewall=yes , что позволит фильтровать DHCP-пакеты непосредственно в IP Firewall

В IPv6 ситуация уже обстоит иначе - DHCPv6-пакеты сначала проходят через IPv6 Firewall прежде чем попасть в DHCP-клиент. С DHCP-сервером не проверял, но предполагаю, что аналогично.

У вас сильно простые примеры.
Если это где то внутри сложной формулы - то лучше явно задать тип, чтобы вызывался соответствующий оператор.

А если еще и перегрузка операторов используется - то вообще без вариантов.
В общем тут дело не в эстетике, а в логике кода. Т.е. есть ситуации когда НУЖНО задавать явно

Во всех случаях мы описали тип слева. Тоесть задача типизации - выполнена.

float a = 1.0f;
unsigned int a = 10u;

Я думаю что ничего дополнительно указывать не надо. В противном случае у code-reviewer
это вызывает удивление и очередной WTF. Тоесть вам придется объяснять своему коллеге
ДЛЯ ЧЕГО вы ввели в исходные код дополнительную информацию.

Нужно писать так чтобы у коллег к вашему коду вообще не возникало вопросов.

При инициализации переменных это обычно не используют. Ну, происходит тут преобразование типа - ошибки быть не может. Это лишь немного снижает читабельность кода и все.

Вот когда вы константы передаете в какие-то перегруженные функции, где имеет значение unsigned ли ей передан или signed, или есть разница между float и double, то тогда - да, надо писать.

Однако с точки зрения оптимизации, эстетики и/или стандартов, как писать все-таки лучше

Как хотите.

На самом деле опциями компилятора можно задать выдавать предупреждения (или даже ошибку) на подобное не явное приведение типов. Тогда это будет "не красиво" или даже вообще ошибка компиляции, и тут вам придется исправлять ситуацию добавив суффикс.
Но подобные опции используют не часто. На сколько помню для gcc это опции -Wsign-conversion и/или -Wconversion но могу ошибаться. И, по моему, они даже не включаются через -Wall -Wextra -pedantic - обычно используют этот набор опций, когда хотят заставить компилятор выполнять больше проверок кода.
Немного модифицировав опции можно добиться не предупреждения, а ошибки.

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

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

Применение сети немного больше чем чья-то одинокая локалка. Так дикари обычно считают - "мы все человечество".
Вот например я произвожу видеокамеры (на самом деле вовсе не видеокамеры). Я вписываю в каждую адрес "по умолчанию" 192.168.1.1 и особо не грею голову, что камера куда-то полезет сраду после включения.

А если бы у нее стоял 200.200.200.1 (адрес принадлежит бразильской телекоммуникационной компании Embratel и находится в Рио-де-Жанейро - именно там, где все негры в белых штанах :)) - она как знать, могла бы и подключиться :)

Если на mikrotik3 только 1 радиомодуль то никак

Облако - означает, что вы точно не знаете на каком именно железе крутится ваш сервис.
Ранее, для каждой виртуалки явно назначали на каком физическом сервере эта виртуалка будет жить. С приходом понятия "облако", железки объединяются в некий кластер, и уже контроллер этого кластера-облака выбирает где запустить вашу виртуалку, или в случае кубера ваш контейнер.

Таким образом в ДЦ можно просто поставить сервера и четко размапить на каком сервере что крутится, или в ДЦ можно поставить сервера и настроить на них "облако".

Дц - это физический объект.

Облако - обобщеный способ разворачивания софта

70-C9-4E-54-03-2F, Загляните в Tools -> Packet Sniffer. Впишите туда "UDP" и 67-ой порт, и смотрите, какие пакеты откуда-куда приходят-уходят. Если правила работают - то будет логирован только приход пакетов на физический интерфейс, но не ответы на них... Поможет найти "мокрый пол".

P.S. Ну и логирование работы DHCP Server, тоже полезно видеть.

P.P.S. DHCP рассылаются броадкастом, может на них отвечает кто-то другой?

Это скорее всего не твой IP. А адрес роутера.
Судя по всему вифи у тебя не очень работает, вот и всё

по умолчанию int является signed

А вот о char этого сказать нельзя, знаковость char зависит от реализации. Вдобавок, в стандарте есть следующая сноска (https://www.open-std.org/JTC1/SC22/WG14/www/docs/n... 6.2.5:15):

Irrespective of the choice made, char is a separate type from the 
other two and is not compatible with either.

signed char -- это, пожалуй, единственное не вызывающее вопросов применение ключевого слова signed в C-коде написанном человеком. В остальных случаях роль signed -- чисто декоративная.

Вмешалась ОС? Но если так, то почему?

Потому что классическая ошибка - использование неинициализированного указателя. Ты обьявил a указателем на целое, но не присвоил ему никакого значения (через malloc(), calloc() или функции, возвращающие указатель). Обьявленная переменная была выделена в куче и получила какое-то мусорное значение, доступное твоей программе (вполне может быть указатель на часть кода, например, на ядро, на общие функции). Ты его прочитал.
При попытке записать по данному адресу поймал SIGSEGV, потому что данный адрес твоей программе по записи недоступен. Все, как должно быть.

могу ли я указателю дать ссылку на конкретную ячейку в памяти?

Теоретически можешь, но практически ось тебе сразу выдаст SIGSEGV, потому что писать ты можешь только в те области памяти, которые тебе доступны по записи.

warning: initialization of 'int *' from 'int' makes pointer from integer without a cast

Ну правильно говорит - инициализация делается без приведения типа. Такой финт ушами часто делают со строками - по умолчанию выставляя там указатель на NULL (что обычно означает, что строке еще не выделялась память), напрмер
char *str = (char *) NULL;