Кресты / Говнокод #15602 Ссылка на оригинал

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
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
// Шифровка текста.

char* encryption(char *Text){
   int i = 0;

   while(Text[i]){
      switch(Text[i]){
         default:
            Text[i] = '.';
            break;
         case 'a':
            Text[i] = ',';
            break;
         // ...
      }
      i++;
   }
   return Text;
}

Русские программисты обеспечивают безопасность данных ФСБ.

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

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

  • я надеюсь у них там вся UTF-16 указана в этом кейсе. а чего? если уж и быть мудаками, то до конца.
    Ответить
    • Енамы генеримые питоном я уже видел - теперь свитчкейс, настало время твое время.
      Ответить
        • ну видимо, питоний скрипт, который на билде генерит плюсовый сорец. Иногда это нормальная практика, самого иногда мысли посещали
          Ответить
          • Правильно, только возникают проблемы с версионированией, да вообще обслуживанием рабочих копий.
            Ответить
            • > возникают проблемы с версионированией
              Какие? В систему контроля версий добавляешь только питоний скрипт. В сгенеренный файл ничего руками не пишешь, под контроль его не добавляешь (его будет генерить сборочная система). Вот и все, и никаких проблем 🙂

              P.S. Есть только мелкая проблемка - в IDE не сразу будут появляться подсказки по этому файлу. Но это решается банальной сборкой проекта.
              Ответить
          • Питоний скрипт, который генерит прогу на крестах, которая генерит питоний скрипт. Сооруди себе уробороса.
            Ответить
      • для того, чтобы нагенерить такой код, нужно иметь где-то нужно иметь маппинг этих символов. или вы предпочитаете рандомно его генерить?
        если уж на то пошло, то для этого даже питон не нужен, можно в экселе его нагенерить. мне когда лень грузить данные из экселя в базу через всякие загрузчики, то я там генерю insert скрипты
        Ответить
        • И это была Экселесина, скрипт разпарсивал ее, текстовую информацию клал в какой-то свой файл (хуй пойми какого формата), а из айдишнегов собирал енамы такие, по несколько сот значений. А вообще все это было нужно для созданиия локализационной инфы в игре.
          Ответить
  • Эм, я не спец и всё такое, но... а разве ветки после default: отработают как надо?

    Имхо оно заменит текст точками и всё.
    Ответить
    • Зато шифрование надёжное. Оно проходит все испытания, кроме терморектального криптоанализа.
      Ответить
    • > а разве ветки после default: отработают как надо?
      Да. Порядок меток в свиче не имеет никакого значения. Это же всего лишь метки, по которым управление впрыгивает в большой блок...

      Скорее всего первая версия switch'а транслировалась во что-то типа:
      do {
          int * jumptable[] = { branch_default, branch_a, branch_b, ...};
          goto jumptable[i];
      branch_default:
          ...
          break;
      branch_a:
          ...
          break;
      } while (0);
      И эта сишкоблядская деталь реализации до сих пор зияет из сишки, крестов и даже жабы...
      Ответить
        • OMG! Никогда бы не подумал что можно и так изъебнуться.
          Сохронил!
          Ответить
          • Да, но вроде как K&R компилятор тоже так умел в свое время.
            Ответить
            • Идея хранения ссылок на метки и перехода по ним мне нравится.

              А если метки ведут на участки кода, равномерно отстоящие друг от друга, то можно ли вообще вычислить адрес, а не брать из таблицы?

              Видимо

              void* a = &&first + (&&second-&&first)*i;
              goto *a;
              first :
              ...
              second :
              Ответить
              • Над этими метками работает обычная адресная арифметика (ведь это самый обычный void *). Но это уже на свой страх и риск. Ведь хуй бы знал, как там компилятор составит код... Одинаковые фрагменты исходника вполне могут иметь разную длину в бинарнике.
                Ответить
                • Да, жаль, но для двух меток гарантированно прокатит.
                  Ответить
                  • Для двух меток можно и goto *(cond ? &&label1 : &&label2) написать.
                    Ответить
                      • А gcc тернарники любит оптимизировать в вычисление. Так что выхлоп, скорее всего, получится почти одинаковый.
                        Ответить
                      • >>А у меня - вычисление!
                        Предсказателю переходов и блоку упреждающего исполнения это очень понравится.
                        Ответить
                        • Косвенный переход в goto * ему понравится гораздо больше. А вычисление будет все-таки чуть эффективнее лишнего перехода перед goto *.
                          Ответить
                          • То был сарказм.
                            Таблицы виртуальных функций и косвенные переходы цп таки как-никак научились ускорять. А "умное" вычисление адреса ставит крест на перфомансе, именно поэтому в интеле такие трудности со сменой eip.

                            > лишнего перехода перед goto *.
                            cmov
                            Ответить
                            • > как-никак
                              Да никак 😉 Вроде бы для косвенных переходов был тупой кеш на одно последнее значение (предполагаем, что прыгнут в то же самое место). Или там что-то поумнее нынче?
                              Ответить
                              • Не.
                                > был тупой кеш на одно последнее значение
                                Там уже всё гораздо умнее.

                                Деталей не помню, но кажись еще в core 2 и последующих интелах какую-то оптимизацию придумали. Потом и амд запилила.
                                Ответить
                              • http://www.agner.org/optimize/microarchitecture.pdf

                                3.12 Indirect jumps on older processors Indirect jumps, indirect calls, and returns may go to a different address each time. The prediction method for an indirect jump or indirect call is, in processors older than PM and K10, simply to predict that it will go to the same target as last time it was executed.

                                Indirect jump prediction An indirect jump or call is a control transfer instruction that has more than two possible targets. A C++ program can generate an indirect jump or call with... a virtual function. An indirect jump or call is generated in assembly by specifying a register or a memory variable or an indexed array as the destination of a jump or call instruction. Many processors make only one BTB entry for an indirect jump or call. This means that it will always be predicted to go to the same target as it did last time. As object oriented programming with polymorphous classes has become more common, there is a growing need for predicting indirect calls with multiple targets. This can be done by assigning a new BTB entry for every new jump target that is encountered. The history buffer and pattern history table must have space for more than one bit of information for each jump incident in order to distinguish more than two possible targets. The PM is the first x86 processor to implement this method. The prediction rule on p. 12 still applies with the modification that the theoretical maximum period that can be predicted perfectly is mn, where m is the number of different targets per indirect jump, because there are mn different possible n-length subsequences. However, this theoretical maximum cannot be reached if it exceeds the size of the BTB or the pattern history table.
                                Ответить
                  • Да можно и трёх (и выше) произвольных! значений выбирать нужное вычислением.
                    Просто от произвольности этих значений зависит сложность формулы выбора.

                    В общем виде формула смотрится примерно так
                    f(x) = ((-(x = c)) & (a - c)) + ((-(x = a)) & (b - c)) + c
                    где a-c, b-c - константы
                    Ответить
              • >хранения ссылок на метки и перехода по ним мне нравится
                по сути изменение eip/rip

                > участки кода, равномерно отстоящие друг от друга
                Только на risc-архитектурах где инструкции имеют фиксированную длину, на x86 с его разношерстными командами такое вряд ли сработает.
                Ответить
      • и даже js, с#, php etc
        >>Скорее всего первая версия switch'а транслировалась во что-то типа
        Еще в фортране/бейсике был похожий оператор, только там явно были номера меток.

        В лично том бейсике на котором кодил я такой фичи не было, но я слышал про диалекты с оной.
        А вот в фортране называлоьс computed goto
        GO TO (label-list)[,] expr
        label-list 
        Is a list of labels (separated by commas) of valid branch target statements in the same scoping unit as the computed GO TO statement. (Also called the transfer list.) The same label can appear more than once in this list.
        GO TO (12,24,36), INDEX

        http://h21007.www2.hp.com/portal/download/files/unprot/fortran/docs/lrm/lrm0124.htm
        Ответить
        • У меня на приставке, емнип, работало тупо GOTO N, где N - номер строки.
          Ответить
            • Даже. Я там в качестве свичей писал что-то в духе GOTO 300 + I * 10
              Ответить
                • А вот это не помню. Надо будет запустить под эмулятором этот G-BASIC да посмотреть. У меня где-то ROM валялся с ним.
                  Ответить
              • Там было другое: утянутый с фортрана предшественик свича ON I GOTO 10,20,30
                Если I не [1,2,3] оно вроде просто проваливалось вниз.
                Ответить
                • Да, я нагнал. Сейчас запустил на эмуляторе - работает только ON I GOTO 10,20,30 ;(
                  Ответить
                  • Ну вот. Даже в бейсике - ON X GOTO - стандарт.
                    А GOTO X - гццизм.Я раньше всегда мечтал об такой фиче, но в реале никогда не видел
                    Ответить
              • А ничё, что номера строк очень любят меняться по ходу написания программы?
                Ответить
                • В бейсике была такая практика ставить номера меток кратными десяткам.
                  Я сначала не въехал, но как мне объясняли сиё было полезно чтобы вставлять между ними код, а номера не менялись.
                  Ответить
                    • Смотря где, по ситуации я и сотню ставил когда планировалось вписать много кода.
                      Потому метки в олд-бейсик-проги и выглядят:
                      10
                      20
                      30
                      Ответить
                • Номера строк писались программистом. Поэтому менялись редко.
                  Ответить
      • >Порядок меток в свиче не имеет никакого значения.
        Это если бряки присутствуют.
        Ответить

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

Где здесь C++, guest?!

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


    8