Его до сих пор используют на первых курсах при обучении азам программирования. Язык как язык.
И что считать «мертвым»? Delphi выпускается, новые среды выходят регулярно, фреймворки под все что угодно, в том числе мобильные устройства, есть.
О, в тему.
Релизовывал недавно для интереса сжатие по алгоритму LZW, полученные коды кодировал переменной длиной по Хаффману. Что меня удивило, так это то, что на примерах простых текстов с очень большим количеством повторений, сжатие не было таким уж эффективным по сравнению с другими алгоритмами. Например, файл лога, в котором очень много повторений (пути файлов и т.д.) при кодировании LZW+Huffman файл длиной 83729 байт ужался до 11568. Вроде, неплохой результат, но 7z или gzip (алгоритм deflate?) ужимают тот же файл до 3906 байт с учетом заголовка архива. Т.е. практически втрое сильнее.
При сжатии EXE файла, 45056 байт ужались моей реализацией до 27788, gzip'ом — до 21518.
Неужели может быть такой разброс? Хороших статей на тему сравнения эффективности алгоритмов именно для связки lzw+huffman не видел. Кто-лбио встречал такое сравнение? Имеет собственный опыт?
Секундочку, я могу согласится, что «присвоение указателю NULL не означает присвоение ему 0», но остальное — спорно. Т.к. повсеместно выполняются прямые арифметические действия с указателями через приведение к целочисленному. Вы не будете так добры и сошлетесь на конкретные пункты стандарта?
буквально: есть "->" — есть разыменование, а если по указателю может быть 0 — то и неопределенное поведение.
В ответе сказно:
неопределенное поведение происходит из попытки обратиться к полю ПОСЛЕ разыменовывания нулевого указателя – само по себе разыменовывание нулевого указателя не ведет к UB
еопределенное поведение происходит из попытки обратиться к полю ПОСЛЕ разыменовывания нулевого указателя – само по себе разыменовывание нулевого указателя не ведет к UB
Ага, т.е. взятие адреса в обсуждаемом примере таки не UB.
Ведь при &p->field обращения к полю нет.
512 байт — большой объем данных. Но дело не в размере, а в том, что это блок, не терминал.
Диск — блочное устройство, никто даже с флопчиком, даже MS-DOS, не работает через порты. Все через DMA.
Я представляю разницу в скорости работы с DMA и без — приходилось писать драйвер для флопчика.
512 байт это уже большой объем. Думаю, при старте НМД работает в режиме совместимости.
Потому что тот же загрузочный сектор будет подгружать части системы поначалу черед БИОС. Так что эта часть должна быть стандартна.
Я уже два раза про это писал выше, работая по сигнатуре мне не нравится тем, что не будет полной уверенности, что это правда часть ядра, которая сейчас запрашивается, чтобы быть исполненной процессором. eEye, на который вы ссылались, патчит драйвера после загрузки в памяти, когда уже точно понятно, что это исполняемый код и часть ядра.
Или я путаю eye с чем-то другим, или там было два варианта (по-моему, да, было две версии этого концепта) и один из них патчит как раз ядро.
И уверенность есть по одной простой причине — ядро грузится первым, после нахождения первой цепочки детектор сигнатуры выключается. А на все ядро (а точнее, eeye не ядро патчит, а загрузчик второй стадии) такая цепочка байт одна. Ну это если верить их, POC создателей исследованиям.
Заменить загрузочный сектор, чтобы запустить вирус не в пример легче.
Нудык, а загрузочный сектор подмененный что потом делать будет? То же самое.
Вовсе необязательно. Мы указываем формат файла. Случай не совсем синтетический, выше уже упоминали некоторые ОС. Т.е. я его, конечно, выдумал, чтобы не было споров о частностях, но это реальный сценарий.
И адрес для NULL задан в stdef путем определения #define NULL ((void*)0).
И было бы логично, если бы мы моглм поменять этот дефайн.
Например, в Windows в подсистеме виртуальной памяти хоть для x86, хоть для IA-64 по нулевому адресу гарантированно нельзя разместить объект.
А толку? Допустим, я компилирую PE / elf модуль под другую ОС (кто сказал, что PE только для MS?), где адрес 0 — корректный. И, допустим, PE заголовок (MZ точнее) аккурат в virtual address space'е процесса по адресу 0 маппируется. А NULL все равно будет численно равен 0. А там, по адресу 0, лежит нужная структура. Ну вот, синтетический случай такой.
и уже не надо ловить файлы на диске по сигнатуре или реализовывать работу с ФС.
Любой сущности, которая может анализировать содержимое блока, нет нужды работать с ФС в данном случае.
Замечание с DMA — существенное. Но разве MBR не будет тоже читаться в память через DMA? Я к тому, что если MBR идет через DMA, то и его подменить нельзя будет. А раз его можно, несмотря на DMA, то и прочие можно тоже.
Гуглится за 10 секунд:
www.slideshare.net/symantec/white-paper-w32ramnit-analysis
И что считать «мертвым»? Delphi выпускается, новые среды выходят регулярно, фреймворки под все что угодно, в том числе мобильные устройства, есть.
Релизовывал недавно для интереса сжатие по алгоритму LZW, полученные коды кодировал переменной длиной по Хаффману. Что меня удивило, так это то, что на примерах простых текстов с очень большим количеством повторений, сжатие не было таким уж эффективным по сравнению с другими алгоритмами. Например, файл лога, в котором очень много повторений (пути файлов и т.д.) при кодировании LZW+Huffman файл длиной 83729 байт ужался до 11568. Вроде, неплохой результат, но 7z или gzip (алгоритм deflate?) ужимают тот же файл до 3906 байт с учетом заголовка архива. Т.е. практически втрое сильнее.
При сжатии EXE файла, 45056 байт ужались моей реализацией до 27788, gzip'ом — до 21518.
Неужели может быть такой разброс? Хороших статей на тему сравнения эффективности алгоритмов именно для связки lzw+huffman не видел. Кто-лбио встречал такое сравнение? Имеет собственный опыт?
В ответе сказно:
В куске &p->a нет обращения к полю а.
Ага, т.е. взятие адреса в обсуждаемом примере таки не UB.
Ведь при &p->field обращения к полю нет.
Диск — блочное устройство, никто даже с флопчиком, даже MS-DOS, не работает через порты. Все через DMA.
Я представляю разницу в скорости работы с DMA и без — приходилось писать драйвер для флопчика.
Я уже говорил — я не знаю возможностей контроллера и как он работает. Это было предположение.
Замнем, как говорится, для ясности.
Потому что тот же загрузочный сектор будет подгружать части системы поначалу черед БИОС. Так что эта часть должна быть стандартна.
Или я путаю eye с чем-то другим, или там было два варианта (по-моему, да, было две версии этого концепта) и один из них патчит как раз ядро.
И уверенность есть по одной простой причине — ядро грузится первым, после нахождения первой цепочки детектор сигнатуры выключается. А на все ядро (а точнее, eeye не ядро патчит, а загрузчик второй стадии) такая цепочка байт одна. Ну это если верить их, POC создателей исследованиям.
Нудык, а загрузочный сектор подмененный что потом делать будет? То же самое.
И адрес для NULL задан в stdef путем определения #define NULL ((void*)0).
И было бы логично, если бы мы моглм поменять этот дефайн.
Ан нет.
А толку? Допустим, я компилирую PE / elf модуль под другую ОС (кто сказал, что PE только для MS?), где адрес 0 — корректный. И, допустим, PE заголовок (MZ точнее) аккурат в virtual address space'е процесса по адресу 0 маппируется. А NULL все равно будет численно равен 0. А там, по адресу 0, лежит нужная структура. Ну вот, синтетический случай такой.
PS C++ в данном контексте не интересен.
Любой сущности, которая может анализировать содержимое блока, нет нужды работать с ФС в данном случае.
Замечание с DMA — существенное. Но разве MBR не будет тоже читаться в память через DMA? Я к тому, что если MBR идет через DMA, то и его подменить нельзя будет. А раз его можно, несмотря на DMA, то и прочие можно тоже.