Няшная / Говнокод #20090 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
# define l2cn(l1,l2,c,n) { \
                        c+=n; \
                        switch (n) { \
                        case 8: *(--(c))=(unsigned char)(((l2)>>24L)&0xff); \
                        case 7: *(--(c))=(unsigned char)(((l2)>>16L)&0xff); \
                        case 6: *(--(c))=(unsigned char)(((l2)>> 8L)&0xff); \
                        case 5: *(--(c))=(unsigned char)(((l2)     )&0xff); \
                        case 4: *(--(c))=(unsigned char)(((l1)>>24L)&0xff); \
                        case 3: *(--(c))=(unsigned char)(((l1)>>16L)&0xff); \
                        case 2: *(--(c))=(unsigned char)(((l1)>> 8L)&0xff); \
                        case 1: *(--(c))=(unsigned char)(((l1)     )&0xff); \
                                } \
                        }

https://github.com/openssl/openssl/blob/6218a1f57e7e25a6b9a798f00cf5f0e56a02ff31/crypto/des/des_locl.h#L151
Интересно, на кой им делать там &0xff если оно в unsigned char скастовано и лишние биты там уже обрезаны? Или они там предполагают что unsigned char может быть не 8-битным? И вообще, это какая-то херня, почему б просто не узнать endian и не сделать memcpy предварительно развернув байты в случае необходимости? Другого макроговна там тоже хватает

Запостил: j123123 j123123, (Updated )

Комментарии (24) RSS

  • # elif defined(__GNUC__) && __GNUC__>=2 && !defined(__STRICT_ANSI__) && !defined(OPENSSL_NO_ASM) && !defined(OPENSSL_NO_INLINE_ASM) && !defined(PEDANTIC)
    #  if defined(__i386) || defined(__i386__) || defined(__x86_64) || defined(__x86_64__)
    #   define ROTATE(a,n)   ({ register unsigned int ret;   \
                                    asm ("rorl %1,%0"       \
                                            : "=r"(ret)     \
                                            : "I"(n),"0"(a) \
                                            : "cc");        \
                               ret;                         \
                            })

    Похоже что они не очень хорошего мнения об оптимизаторах gcc и clang раз считают нужным писать такие асмовставки
    Ответить
    • к тому же в gcc(да и в clang тоже, они там все за gcc повторяют зачем-то) для этого есть интринсик
      Ответить
      • Хотелось быиузнать в асм какой машины интрисит шланг
        Ответить
          • Правильно. Для ллвм. А оттуда ее бекенд делает асм под арм интел итд. Так в каком месте появляется интринсик?
            Ответить
            • Дык интринсик в обход си, которое не позволяет по-человечески выразить все эти rol'ы. В самой llvm эти команды, наверное, есть.
              Ответить
                  • Не знаю. Мне просто интересно как протащить интринсик через 2 уровня абстракции. В жабе тоше есть интринсики правда, но там о них jvm знает
                    Ответить
                    • Ну если llvm позволяет добавлять кастомные инструкции - можно. Но тогда получается неявная договорённость между компилятором и генератором нативного кода. Плюс получится IR, который понимают только они, что портит всю идею llvm...
                      Ответить
      • ЕМНИП, интрисинк для поворотов есть только в студии, а в остальных есть оптимизация двух сдвигов и | до одной инструкции.
        Ответить
  • > l2cn
    Какие охуительные названия макросов. Интересно, почему большинство людей, дорвавшись до препроцессора, начинают аццки экономить байты исходников, даже если до этого были вполне вменяемыми остальным сущностям дают чёткие и понятные имена?..
    Ответить
    • Всю жизнь сишника ебали и били палкой за короткие имена, макросы и битоёбство без повода. Но вот, в один прекрасный день, какой-то фрагмент кода всё-таки упёрся в производительность. И сишник на пару дней обрёл свободу...

      Завтра его снова будут ебать и бить палкой. Но сегодня ему можно всё.
      Ответить
  • >Или они там предполагают что unsigned char может быть не 8-битным?
    Если это код для каких-нибудь сраных контроллеров, то может. Но в таком случае возникает вопрос о типе "c" и поведении этого кода. Плюс на портабельность в таком случае давно положен хуй и можно пользоваться знаниями о конкретной архитектуре.
    Ответить

Добавить комментарий

Я, guest, находясь в здравом уме и твердой памяти, торжественно заявляю:

    А не использовать ли нам bbcode?


    8