int to bytes (char*)

Почему буфер L пуст?

Потому что функция strlen() натыкается на \0 в первом элементе массива.

Помогите получить char *L с реально заполенными 4-мя символами (байты числа 55).

Используй snprintf(), например.

// 0 0 0 37

Извини, но что-то я не понял. Здесь 0, а не \0. Мне нужно именно 4-х байтовое представление числа, в примере 55, а не 55 в строке.

хрень какая то получается

 snprintf ( L, 4, (bL >> 24) & 0xFF, (bL >> 16) & 0xFF, (bL >> 8) & 0xFF, bL & 0xFF ); // 0 55 0 0 and strlen(L) = 0

Здесь 0, а не \0

это одно и то же, бгг

strlen определяет не размер буфера а позицию первого встретившегося нуля. У вас он в начале, поэтому возвращается 0.

& 0xFF

А, для этого тебе четырех чаров не хватит, конечно же.

Man sprintf

Кстати, в связи с тем, что в цпп20 знаковый числа - two’s complement, прописали явно поведение при касте в signed:

If the destination type is signed, the value does not change if the source integer can be represented in the destination type. Otherwise the result is the unique value of the destination type equal to the source value modulo 2n where n is the number of bits used to represent the destination type. (since C++20).

раньше было implementation-defined.

Здесь 0, а не \0

https://www.youtube.com/watch?v=KI4g0-_GsiY

strlen для массива бинарных данных, серьезно что ли? Всё у тебя по идее верно, просто зачем ты пытаешься получить его длину способом, пригодным лишь для null-terminated строк?

исправил

const char* L = reinterpret_cast<const char*>(&bL);

точнее #if __x86_64__ || ... потому что некоторые архитектуры ещё не любят не кратных 4байт+ адресов

ну или заранее сделать так, чтобы адрес был выровнен

Не вижу проблемы пока ты в рамках одной системы и не пытаешься потом работать с этим как с null terminated string.

const char* L = reinterpret_cast<const char*>(&bL);

это UB.

На cppcon 2019 в докладе про bitcast представитель комитета С++ рассказывал почему это UB во всех С++ включая С++20, и сказал что комитет почти договорился дополнить стандарт чтобы это перестало быть UB в С++ 23.

https://i.imgur.com/seTYGS6.png

Корректное решение без UB на текущий момент:

https://i.imgur.com/VIIVBbi.png

Ссылка есть? Только не на видосик

На что тебе нужна ссылка?

Пересмотрел ещё раз видосик. Вот пропозал в С++23, который устранит UB, а до тех пор это UB.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1839r2.pdf

На пропозал как раз подойдёт

Спасибо

В общем, это продолжение той бодяги, которую std::launder решал. Ну и заодно к char разрешили без него приводить

Без этого все сокет api накроется как и memcpy. Тут исключение для char* относительно strict aliasing.

Без этого все сокет api накроется как и memcpy

Так и есть, в рамках текущего стандарта С++ невозможно реализовать свой memcpy без UB. Об этом тот тип из комитета в видосике и говорил, и поэтому они и правят стандарт, вот с С++23 если всё норм будет, то программист С++ сможет реализовать свой memcpy.

Эта новость, что в компиляторах достаточно магии? Можно открыть любую стандартную библиотеку и посмотреть на количество компиляторных интрисиков. Не вся стандартная библиотека написана на стандартном С++…

Вот можешь послушать 1 минуту: https://youtu.be/_qzMpk-22cc?t=2827

strict aliasing ни при чём, там доступ через «старый» pointer value

Такое объяснение сойдёт? https://stackoverflow.com/a/62341088/

Из забавных последствий этих pointer values:

unsigned u;
(int&)u = -1;

В u теперь хранится значение -1. Не положительное значение, которое сравнимо с -1 по модулю, а именно -1. Читать такой u теперь можно только через lvalue типа int или char, если его диапазон включает отрицательные числа, но не через lvalue типа unsigned/unsigned char.

strict aliasing rules говорят, что у тебя будет UB при доступе через glvalues неправильны типов, но не гарантируют что UB не будет при чтении с правильными типами. «p → q» не эквивалентно «!p → !q».