блин, два здравых коммента во всём треде. этот и анонимуса.

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

Не слушай тех, кто советует так и делать, в общем случае использование указателя не того и не совместимого по указателям типа, объект которого лежит по этому адресу - UB. Исключение в стандарте сделано только для char* - его можно приводить к указателю на что угодно. Причина - компиляторам позволено строить свои оптимизации, исходя из предположения, что раз указатели не совсемстимых типов - значит они точно не указывают на одно и то же, а значит изменение значения по указателю A не может влиять на значение по указателю B

Исключение в стандарте сделано только для char* - его можно приводить к указателю на что угодно

Почему ламерки так часто понимают strict aliasing rules как правила приведения указателей?

Ты бы лучше на вопрос ответила

в C++ так нельзя

Можно, но только если uint8_t является алиасом для ((un)?signed)? char

И да, почему так нельзя в С++?

strict aliasing violation

Ну попробуй сделать static_cast из char* в int*. Сразу ударит по рукам

reinterpret_cast. Ну или static_cast через void*. Если не разименовывать, даже UB не будет

Вот представь, тебе надо прочитать бинарные данные из файла в некую структуру

Тогда для буфера юзается char, а не uint8_t

элементарные манипуляции с указателями

Ага, а потом у них clang стандарт не реализует, strcat не копирует и остальное в подобном роде

вы перед тем как бежать на форумы флудить, сначала бы книжки умные почитали. тут сверху прилеплена тема про всякие книжки по основам разных языков, в том числе С и С++. там на первых же страницах всё поясняется. про память, адресацию, указатели, выравнивание и вот это всё.

в C++ так нельзя

Можно, но только если uint8_t является алиасом для ((un)?signed)? char

И если в буфере до этого был создан объект типа uint32_t с использованием placement new.

И ещё указатель после каста надо отмыть launder-ом.

объект типа uint32_t

Звучит как-то по-питоновски.

При условии что cnt в рамках - все норм.

если uint8_t является алиасом для ((un)?signed)? char

А он может быть алиасом на что-то другое?

Вроде и сказала много, а по теме так и ничего

Тебе уже на него много раз ответили, но ты так и не сказал ничего про endianness

Да ни при чём тут endianness или выравнивание. Про strict aliasing правильно написали.

Мать, если тебе очень хочется отметиться в обсуждении, то вместо флуда и прокачки чсв ответила бы по существу. Что написано в книжках я без твоего совета знаю, но как показывает практика каждый такой начитанный поциент лепит как хочет, а потом вот так же, ковыряясь в сносу, рассказывает про «элементарные операции», ага

reinterpret_cast не портируем же. Через static_cast и void* да, по правилам выходит, что можно. Но тут простая сишка и разыменование

reinterpret_cast не портируем же. Через static_cast и void* да, по правилам выходит, что можно.

reinterpret_cast это и есть static_cast через void* (в случае каста указателей)

http://eel.is/c++draft/expr.reinterpret.cast#7.sentence-2

When a prvalue v of object pointer type is converted to the object pointer type “pointer to cv T”, the result is static_­cast<cv T*>(static_­cast<cv void*>(v)).

Да endianness какой угодно можно сделать. Если переформулировать вопрос, меня интересует, канает ли в обычной сишке strict aliasing rule и является ли оное говнокодом

Ок. Но все равно не портируемо

Что ты понимаешь под «не портируемо»?

Поведение static_­cast<cv T*>(static_­cast<cv void*>(v)) полностью определено и не содержит implementation-defined операций.

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

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

я хочу сказать, что два поста тут были по делу

Комментарий от анонимуса, который здравый (и по делу), это Это UB? (комментарий) ?

Только если buf не выровнен по sizeof uint32_t то привет sigbus на power

Это не манипуляции с указателями это нарушение strict aliasing

В c++ c style cast работает несколько иначе чем ты думаешь(p.s. не как reinterpret)

Разумеется. Про выравнивание тоже сказали неоднократно

Хз. Вообще-то, исходя из лимитов таки не может, да

reinterpret_cast не портируем же

Не портируем в _большинстве_ случаев. Тот самый strict aliasing и есть портируемые приведения

Тот самый strict aliasing и есть портируемые приведения

Это UB? (комментарий)

Это не манипуляции с указателями это нарушение strict aliasing

что по сути — код с достаточно ясным намерением ломает тупой оптимизатор. Вот K&R этот код ничего не ломал, пока выполнялись условия по выравниванию (а на PDP за это били больно) и порядку следования (там были занятное endian, не big и не low, а именно pdp-endian), совсем недавно такого кода было вагон, начиная со всяких парсеров jpeg-ов и кончая FS и RPC. А теперь видите-ли нельзя, потому что оптимизатор может заалиасить память, но не обновить. Можно подумать, при перемещении порядка байт данные в них ломаются, а выравнивание — это такая случайная величина, которую предсказать никак нельзя...

Вот K&R этот код ничего не ломал

Предлагаю вернуться к C времён 1971-го года. Там даже так можно было:

struct S1 { int a; int b; int c;};
struct S2 { int a; int b; }

struct S2 s2;
s2.c; /* ОК, хотя в struct S2 нет никакого c */

Это отличная демонстрация эффекта «o tempora, o mores». Ибо когда это «починили» об анонимных структурах не подумали и родилось ЭТО: struct sockaddr_in { struct in_addr { in_addr_t s_addr; }; ... }

канает ли в обычной сишке strict aliasing rule и является ли оное говнокодом

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

мы там решили, что strict aliasing - говно, но надо доработать стандарт, чтобы компиляторы не хулиганили.

В комитете ламерков с ЛОРа забыли спросить.

Почему ламерки так часто понимают strict aliasing rules как правила приведения указателей?

Потому что вы выдаёте за непреложную истину свои мысли, весьма далёкие от реальности

Связь, кстати, я не слишком уловил

Ещё и uninitialized, лол

Там решили, что олдфаги сишники, считающие язык «обёрткой над ассемблером», неправы

Я тоже не уловил связь strict aliasing с портируемостью reinterpret_cast.

Хз, вроде ясно написал

Что такое «портируемость»?

Корректная работа с хорошо определённым(и одинаковым, соответственно) поведением на разных платформах/архитектурах

Поведение static_­cast<cv T*>(static_­cast<cv void*>(v)) полностью определено и не содержит implementation-defined операций.

Ладн, исправляюсь. Значение может быть unspecified, если адрес не выровнен для типа T.

Зависимость результата от сопутствующих факторов (архитектуры, например)

при этом назвав «наркоманией» абсолютно валидный и тривиальный код

И чем докажешь «абсолютную валидность»? Этот код нарушает strict aliasing rule. Ты же технически подкованный человек, выражайся конкретно, предъявляй пруфы. Но ты походу настолько безграмотна, что даже не почесалась от нарушения стандарта

Забей на тетку, она настолько непроходима что даже не понимает чего не понимает. Большой опыт иногда не идет на пользу.

Ну их, эти касты.

memcpy (&size_pic, &buf[cnt], sizeof size_pic);