P
сдвиги - это реальное проц. время. а тут по-идее должно скомпилиться в 0 ассемблерных команд)
Size: a a a
2021 January 24
ED
Не исключено, что оптимизатор превратит сдвиги в точно такое же обращение.
ED
Ну если только не на -O0 компилировать.
P
это да
W
uint8_t buf[22];
uint16_t aaa = *((uint16_t *) &buf[20]);
gcc: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
а чего, как бы это по-красивше сделать чтобы он не ругался? union не хочется в этом месте
uint16_t aaa = *((uint16_t *) &buf[20]);
gcc: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
а чего, как бы это по-красивше сделать чтобы он не ругался? union не хочется в этом месте
У вас UB.
Так делать нельзя.
Так делать нельзя.
P
У вас UB.
Так делать нельзя.
Так делать нельзя.
да можно)
W
да можно)
Это не по стандарту.
За такое надо по рукам давать.
Используйте сдвиги.
За такое надо по рукам давать.
Используйте сдвиги.
ED
У вас UB.
Так делать нельзя.
Так делать нельзя.
А почему UB? Все нормально, но экстравагантно.
W
Это не по стандарту.
За такое надо по рукам давать.
Используйте сдвиги.
За такое надо по рукам давать.
Используйте сдвиги.
Если хотите в компилтайме - то вам в плюсы (constexpr/constint) или раст (макросы).
W
А почему UB? Все нормально, но экстравагантно.
Возможно impl-defined, а не уб (в плюсах - точно уб до с++20).
Но не стандартизированное поведение - точно.
Но не стандартизированное поведение - точно.
P
я вот немного не получил того, что планировал с Флетчером:
если слать просто КС, то в ней никогда не бывает 0xFF байтиков. А вот если слать не КС, а дополнение строки таким образом, чтобы КС по строке + дополнению стала равно 0x0000 - то возникают ситуации, когда дополняющие байтики равны 0xFF. Что не айс мне. Поэтому пришлось делать сравнение полученной и посчитанной КС вместо того чтобы прогнать алгоритм подсчета на стороне приемника и определить что результат == 0
но вроде бы это (кроме фокусов с endianess, которые и так возникают) на полезные свойства самой КС Флетчера не влияет?
если слать просто КС, то в ней никогда не бывает 0xFF байтиков. А вот если слать не КС, а дополнение строки таким образом, чтобы КС по строке + дополнению стала равно 0x0000 - то возникают ситуации, когда дополняющие байтики равны 0xFF. Что не айс мне. Поэтому пришлось делать сравнение полученной и посчитанной КС вместо того чтобы прогнать алгоритм подсчета на стороне приемника и определить что результат == 0
но вроде бы это (кроме фокусов с endianess, которые и так возникают) на полезные свойства самой КС Флетчера не влияет?
ED
Возможно impl-defined, а не уб (в плюсах - точно уб до с++20).
Но не стандартизированное поведение - точно.
Но не стандартизированное поведение - точно.
Чего там нестандартизовано-то? Обычные разыменования с конверсией типов.
P
Если хотите в компилтайме - то вам в плюсы (constexpr/constint) или раст (макросы).
хочу по-старинке)
ED
Сам бы я так не делал, но UB не вижу.
P
что такое UB?
A🐱
undefined behaviour
W
Чего там нестандартизовано-то? Обычные разыменования с конверсией типов.
Нарушением strict aliasing.
L
что-нить в духе`*(uint16_t *)(((void *)buf) + 20)`
P
что-нить в духе`*(uint16_t *)(((void *)buf) + 20)`
pointer of type 'void *' used in arithmetic [-Wpointer-arith]😅