- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
int AzFl_PSD_Image::ReadIntFromPsdFile(const unsigned char *offset)
{
char i[4];
i[0] = offset[3];
i[1] = offset[2];
i[2] = offset[1];
i[3] = offset[0];
int *r = (int*)i;
return r[0];
}
Кресты / Говнокод #12078
0
Невиноватый я что програмисты из адоба биты задом на перед в файл пишут :`(
Запостил: 
Psionic,
(Updated )
Но тут, конечно, зависимость от порядка байт платформы вводится зря. И длина, возможно, не проверяется (а что если файл обрезан, и offset[3] уже за концом?).
Этот код работает всегда и везде (лишь бы инт был 32 бита). А ваш костыль на Big-endian платформе заломается.
http://govnokod.ru/12071#comment159370
И каст char* в uint32_t*? Ну так это тоже костыль. Причем, как я заметил ниже, в отличие от моего костыля еще и будет падать на АРМах с Alignment Fault если offset нечетный.
htonl/ntohl они все-таки для случаев, когда у нас уже есть собранный uint32_t.
пусть платформа сама перевернет, если ей этого надобно
А еще, к примеру, на восмибитных AVR инт занимает 16 бит. Поэтому там ничего не влезет, и автору следовало юзать uint32_t или его аналоги.
Я уж не говорю о процессорах, на которых байт состоит не из 8 бит...
это x86 их задом наперед хранит
в big-endiane они как раз по-человечески распогалаются
0x12345678 хранятся как 12 34 56 78, а на маленьком ендейце будет 78 56 34 12
Да многие так делают. В Qt сериализация в QDataStream по дефолту настроена на Big endian, в ява машинах .class файлы тоже, даже порты в низкоуровневых структурах для работы с сокетами записываются "задом наперед"...
Несмотря на то, что я не видел плохого кода в Вашем исполнении.
Так узри же сейчас!
http://govnokod.ru/11576
http://govnokod.ru/11575
http://govnokod.ru/11528
http://govnokod.ru/10058
http://govnokod.ru/10011
я если чо могу и fpga наваять, который тупо правильно заведенными линиями сразу перевернет - это достаточно низкоуровнево? мне не сложно, зря этому учили чтоли
P.S. Посоветуете кстати чего-нибудь из серии FPGA для нубов?
да и не востребованные
еще спасибо институту, что в наше время уже проектировались, отлаживались в нормальной среде (xilinx), на выходе получая результат в fpga, а не собирали курсовики на стендах проводочками, как за несколько лет до нас
Ну так то да, придумать чего-то оригинальное с FPGA не могу. Все что приходило в голову уже кем-то сделано 😉 Так что вы правы, забью я на это дело.
какой-нибудь железячный шифратор-дешифратор
или биржевые спекулянты ради выигранной 1мс готовы тратить миллионы
а все остальное бытовое - ну какие сейчас еще кому нужны платы расширения
1) Размеры типов не фиксированы. В стандарте написано только то, что sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long), ну и то что sizeof(char) всегда 1 байт.
2) Для хранения размеров всяких структур, лежащих в памяти следует применять size_t, а не unsigned, а если нужно считать разницу между указателями следует применить ptrdiff_t, а не int.
3) Если нужен именно тип фиксированной длины - воспользуйтесь int8_t, int16_t и им подобными. В визуалке вроде бы их нет (ведь настоящим посонам С99 не нужен), поэтому как поступить в ней, мы спросим у @defecate++.
4) Результат знакового переполнения определяется платформой и компилятором (в отличие от переполнения беззнакового, которое специфицировано стандартом), поэтому его лучше избегать, если на то нет весомых причин.
5) На некоторых платформах есть проблемы с доступом к невыровненным данным. Начиная от снижения скорости, и заканчивая крашем с Alignment Fault. Поэтому не стоит бездумно юзать pragma pack и кастовать указатели из char* во что попало.
Вроде бы всё...
sizeof(char) = sizeof(short) = sizeof(int) = sizeof(long) = sizeof(long long) = 1
4. Тут вообще нужно раскрыть тему undefined behavior.
А вообще да. Правило 0.
0) Никогда без весомых причин (а у вас их нет) не используйте undefined behavior. Implementation defined использовать можно, но только если нет возможности написать по-другому.
фактический размер на платформе не имеет права не соответствовать (быть более урезанным) *_MIN, *_MAX, объявленных в стандарте
исходя из них, у short и int - минимум 16 бит длина
у long - минимум 32 бита
у long long - 64
3. есть boost/cstdint.hpp, который либо сам объявит нужные типы, либо возьмет из внезапно имеющегося стандартного аналога от компилятора
> у long - минимум 32 бита
> у long long - 64
Хм. А вот это я как-то пропустил. Сорри за дезинформацию.
> есть boost/cstdint.hpp, который либо сам объявит нужные типы
Ок, спасибо.
P.S. Капча 9999.
не вижу противоречия
можно вообразить платформу, где char, short и int будут занимать по 8 байт (64 бита)
и таким образом будет, например sizeof(char) = sizeof(short) = sizeof(int) = sizeof(long) = 1
так что скорее моя вина, "неправда" относилось к домысленному = 8 бит 🙂
в с++
Тут, конечно, опечаточка: sizeof(char) == 1 by definition in C++, а сколько там байт - зависит от платформы
в с++ ровно так, как сказал Роман
в с на sizeof(char) - как и на другие типы - таких ограничений, как в с++, не накладывается
В стандарде.
6.5.3.4 The sizeof operator
2. The sizeof operator yields the size (in bytes) of its operand
3.When applied to an operand that has type char, unsigned char, or signed char, (or a qualified version thereof) the result is 1.
Так что char это 1 байт.
в с++ при этом так же
единственный вариант - варьировать количество бит в байте
которых должно быть не менее 8 в связи с наложенными лимитами
в с++ раскрывается еще понятие байта в 1.7
Т.е. троичные машины вполне стандартны 😉
P.S. To hold an object. А кто-то еще говорит, что С это не объектно-ориентированный язык.
Это другие байты, и в стандарте си они не рассматриваются. Поэтому противоречий тут нет.
byte
addressable unit of data storage large enough to hold any member of the basic character set of the execution environment
NOTE 1
It is possible to express the address of each individual byte of an object uniquely.
NOTE 2
A byte is composed of a contiguous sequence of bits, the number of which is implementation-defined. The least significant bit is called the low-order bit; the most significant bit is called the high-order
bit.
Jazz <=> Язь
Затем, что исторически он писался под 32 разрядный моторольный процессор 86000 (Мак), в котором порядок байтов обратный интеловскому
может 68000?