LINUX.ORG.RU

Релиз Kaitai Struct v0.4

 , , , ,


2

3

Состоялся релиз v0.4 проекта Kaitai Struct — декларативного языка для описания форматов структур данных. Описание структуры составляется в виде файла .ksy (в простом YAML-подобном виде), а затем с помощью предлагаемого компилятора транслируется в исходный код парсинга (на данный момент поддерживаются C#, Java, JavaScript, Python, Ruby и предварительно — C++). Типичная сфера применения — разбор и импорт существующих бинарных форматов файлов (в том числе закрытых и проприетарных), сетевых пакетов (например, в составе IDS или систем мониторинга трафика) и т. п.

Кроме компилятора, в состав поставки входит визуализатор, с помощью которого удобно отлаживать разрабатываемое описание (особенно, если формат неизвестен и необходимо пробовать много разных гипотез), применяя его сразу к существующему файлу и наблюдая результат парсинга в виде дерева с подсветкой соответствующих элементам этого дерева мест в hex-дампе.

Инструментарий распространяется под GPLv3, используемые в компилируемом коде runtime-библиотеки — под MIT/Apache. Референсный компилятор написан на Scala, но существует версия для веба на JavaScript, работающая в браузере целиком на стороне клиента.

Из нововведений нового major-релиза можно отметить:

  • поддержку 2 новых целевых языков: полная поддержка C# и предварительная — C++ с STL;
  • полную поддержку JavaScript в runtime-библиотеке;
  • поддержку новых типов данных: числа с плавающей точкой и выделенные типы для массивов байт;
  • расширение встроенного языка выражений: добавлены операции для работы с массивами, преобразования типов данных, доступа к объекту потока и т. п.;
  • существенную переработку и унификацию runtime-библиотек всех поддерживаемых языков для приведения их всех к единому API (в рамках дозволенного правилами конкретных языков).

>>> Подробности

★★

Проверено: tailgunner ()
Последнее исправление: CYB3R (всего исправлений: 4)

Ответ на: комментарий от tailgunner

Если поверхностно - то тем, что Construct - только для Python, а KS - для всех поддерживаемых языков. Есть ремейк Construct для Java - но так как описание формата у Construct встроено в исходник на языке программирования - как только пытаешь менять язык - как минимум, все описания придется подгонять под синтаксис нового языка - а в реальности еще и все «lambda: » придется переписать на новом языке.

А если подробнее разбираться:

  • KS - это компилятор, а Construct - интерпретатор. Соответственно, скорость работы сильно разная.
  • Результат работы KS - полноценные статические классы, результат работы Construct - дерево hashmap'ов.
  • По идеологии - KS куда более декларативный. У Construct как только нужно прочитать что-нибудь вне потока - например, структуру по указателю - на этом декларативность заканчивается, надо вручную из Python делать seek в stream и вызывать другой декларативный парсер. В KS это все нормально описывается в самом формате.
  • Наличием отладчика-визуализатора - разбирательство с construct.debug, по-моему, на порядок медленнее - но я, разумеется, не индикатор.
GreyCat ★★
() автор топика

По описанию - очень клёво, но как же это они старый добрый С проигнорировали?

zabbal ★★★★★
()

декларативного языка для описания форматов структур данных. Описание структуры составляется в виде файла .ksy (в простом YAML-подобном виде)

Я посмотрел на сайте - как-то уж очень тяжело сей язык выглядит. Почему нельзя было за основу взять какой-нибудь классический IDL, или даже хотя бы язык Google Protobuf?

// И то это если нужна «равноудалённость» от целевых ЯП, а если такими вопросами не заморачиваться, можно было и парсер сишных POD struct написать :)

hobbit ★★★★★
()
Ответ на: комментарий от zabbal

Не проигнорировали, а уже несколько месяцев пытаемся сделать, но пока все еще в процессе переговоров, как же это должно выглядеть.

Дело в том, что чистый C сильно отличается от всех до сих пор поддерживаемых языков, например, полностью ручным memory management и или, например, невозможностью работать со всем, как с выражением. Даже договориться о том, как представлять те же самые строки или вложенные друг в друга объекты, выделять ли их в хипе или на стеке (и если на стеке - то у кого) - уже целая длинная песня. Плюс совершенно другая модель прерывания работы и репортинга результатов (из-за отсутствия эксепшенов).

GreyCat ★★
() автор топика
Ответ на: комментарий от GreyCat

чистый C сильно отличается от всех до сих пор поддерживаемых языков, например, полностью ручным memory management

Дык необязательно же именно «чистый» - если уж мне всё-равно ваши библиотеки тащить в проект, то тот же talloc тем более не проблема использовать.

zabbal ★★★★★
()
Ответ на: комментарий от zabbal

Во-от, именно вот так оно и начинается. Кто-то хочет talloc, кто-то - gi, кто-то - какие-нибудь vasprintf, кто-то libapr, кто-то хочет настоящий garbage collector и libgc - и пошло поехало. А потом приходят злые эмбеддщики и говорят, что у них 2 килобайта памяти и килобайт 15-20 флешки под код, поэтому весь этот зоопарк зависимостей им совершенно не уперся.

А у нас, кстати, библиотеки совершенно тривиальные, как правило - при желании это все можно заинлайнить и все. Ну, будет не

foo = self._io.read_u4be()

а

tmp_foo = self._io.read(4)
if len(tmp_foo) < 4:
    raise EOFError(...)
foo = unpack('>i', tmp_foo)[0]

4 строчки вместо 1.

GreyCat ★★
() автор топика
Ответ на: комментарий от GreyCat

Вот, вот, не обижайте эмембдщиков111 Как раз jyb в большинстве и юзают до сих пор си. (а флэши у нас уже давно не 10-15кб, а больше 200кб точно, в чуть более дорогих чипах 2мб, а ещё возможность подключения овер9000мб внешней нанд и тд. тож самое и с оперативкой - больше 20кб - точно, а так же можно навешать внешнюю рам :3 (Но вы этого ни слышали с= ))

SL_RU ★★★★
()
Ответ на: комментарий от GreyCat

А потом приходят злые эмбеддщики

Это потому, что у них велосипед без сидушки :) А я добрый эмбедщик - у нас yocto, talloc и systemd.

zabbal ★★★★★
()

Выглядит интересно, спасибо. Особенно нравится наличие визуализатора.

Weres ★★★
()
Ответ на: комментарий от SL_RU

Я как бы сам немножко эмбеддщик, поэтому в курсе :) И эти требования выслушиваю уже не первый год :)

GreyCat ★★
() автор топика
Ответ на: комментарий от EnterpriseMobility

Самое смешное, что про поддержку PHP уже пару месяцев спрашивают, но никто все не решался помочь. А после этого релиза вдруг захотели.

GreyCat ★★
() автор топика

Автор, а обратное преобразование данных в бинарный формат возможен силами этого языка? Если нет, есть ли это в планах?

anonymous
()
Ответ на: комментарий от anonymous

Прямо сейчас нет, есть в планах. Дело в том, что у нас форматы сильно более сложные, нежели просто C-подобные struct.

GreyCat ★★
() автор топика

Что-то я не понял, в разделе meta указывается порядок байтов для всех типов данных в разбираемом файле. А если этот параметр также должен быть прочитан из заголовка (для разбора TIFF, например)? Или единственный выход --- дублировать описание всех структур для обоих порядков?

DronK
()
Ответ на: комментарий от DronK

Справедливое замечание. В текущей версии - да, дублировать + переключать тип в зависимости от прочитанного заголовка. В будущем, вероятно, будет возможность установить default endianness для отдельных типов и подтипов. Тогда, наверное, сделаем что-нибудь типа такого:

meta:
  id: tiff
seq:
  - id: byte_order_id
    type: str
    encoding: ASCII
    size: 2
  - id: header
    type: tiff_header
types:
  tiff_header:
    meta:
      little-endian-expr: '_root.byte_order_id == "II"'
    seq:
      - id: version
        type: u2
      - id: img_dir_ofs
        type: u4
      # ...

Надо только название приличное придумать для этого параметра «little-endian-expr», в котором указывается выражение.

GreyCat ★★
() автор топика
Ответ на: комментарий от GreyCat

Ok, понятно, спасибо за ответ. По предложенной выше схеме возникает такое замечание: если проверка byte_order == «II» будет присутствовать в описании каждого типа, то кодогенератор будет её вставлять в код для чтения каждой соответствующей структуры? Хотелось бы прочитать и установить этот флаг однократно, чтобы все структуры его как-то унаследовали. Хочется краткости и в описании и в коде.

Ещё такой вопрос: а если у меня 10-битные (или, скажем, 14-битные) данные плотно упакованы в сплошную структуру, то как их правильно читать? Только через binary processing? Тогда там требуется расширить набор встроенных функций.

DronK
()
Ответ на: комментарий от DronK

Хотелось бы прочитать и установить этот флаг однократно, чтобы все структуры его как-то унаследовали.

Думаю, что так и надо делать - наследовать. Т.е. сначала в файле идет endian-нейтральная часть заголовка (с сигнатурой, из который определяется endianness), потом отдельным типом оформляется весь остаток файла, а нужные подтипы засовываются под него, т.е. что-то типа:

tiff
├ byte_order
└ tiff_main (где endianness определяется условием на byte_order)
  ├ header (эти все наследуют endianness от tiff_main)
  ├ section1 (и эти...)
  │ ├ subsection1_1 (и тем более эти...)
  │ └ subsection1_2
  ├ section2
  └ ...

Ещё такой вопрос: а если у меня 10-битные (или, скажем, 14-битные) данные плотно упакованы в сплошную структуру, то как их правильно читать? Только через binary processing?

Не очень понял вопрос - что значит «плотно упакованы»? Если нужно побитовое unaligned чтение - то это есть feature requests про bitfields и про возможность менять alignment, в том числе с точностью до бита. Будет в следующих версиях.

Пока же, если данные сколько-нибудь aligned, можно делать трюки типа таких:

seq:
  - id: tmp
    type: u2be
instances:
  bits0_3:
    value: 'tmp & 0b1111'
  bits4_15:
    value: '(tmp & 0b1111111111110000) >> 4'

После чего к полям bits0_3 и bits4_15 можно обращаться полноценно, как к целым. Т.е., в общем, все ровно так же, как их читают в любом C-подобном языке, только без особенного syntactic sugar.

Processing тут вроде бы не при чем особенно. Это штука для работы с форматами-внутри-форматов, когда применяются всякие компрессии, обфускации, шифрование и т.д.

GreyCat ★★
() автор топика

В бектрекинг оно умеет?

В древовидные структуры?

Поддерживают ли получаемые в итоге парсеры буферизированный ввод?

Чем оно лучше attoparsec/любой другой генератор парсеров?

good_riddance
()
Ответ на: комментарий от Deleted

Step 1. Зайти на http://kaitai.io

Step 2. Нажать в навигационном баре «Documentation» и попасть в документацию

Подскажите ради интереса, что из этого составляет сложности? Просто похоже, что вы далеко не первый, кто не может найти описание языка. Люди реально и в почту спрашивают, и в багтрекер. Может, кнопка недостаточно заметная? Или еще что-то?

GreyCat ★★
() автор топика
Ответ на: комментарий от good_riddance

В бектрекинг оно умеет?

Нет, и не будет.

В древовидные структуры?

Разумеется.

Поддерживают ли получаемые в итоге парсеры буферизированный ввод?

Если целевой язык и его stdlibs поддерживают - то да.

Чем оно лучше attoparsec/любой другой генератор парсеров?

https://github.com/kaitai-io/kaitai_struct/wiki/FAQ#-gnu-bison-yacc-lex-flex-etc

Если совсем коротко - то совершенно разного класса подходы и инструменты. Разная сложность разработки и отладки, разная инструментальная поддержка, разные возможности - как следствие - разные сферы применения. attoparsec, кстати, если уж попридираться - еще и совсем не генератор парсеров, а parser combinator. Что, в свою очередь, еще более третий класс инструментов со своими плюсами и минусами.

GreyCat ★★
() автор топика
Ответ на: комментарий от GreyCat

Спасибо

Объясняю: пункт Documentation находится слишком справа, отдельно от Quick Start и Download. То место, где он находится сейчас, у меня ассоциируется со всякими About и платными услугами на похожих по дизайну сайтах, пункт Try It только смущает поэтому. Не заметил, одним словом :)

На странице https://github.com/kaitai-io/kaitai_struct/wiki содержание, находящееся слева, - не заметил

Deleted
()
Ответ на: комментарий от GreyCat

еще и совсем не генератор парсеров, а parser combinator

Спасибо, я в курсе. Эта фраза подразумевала, что её распарсят как «генератор парсеров или библиотека комбинаторов парсеров».

Нет, и не будет.

Fail, есть бинарные форматы где это нужно. К сожалению. Да, за такое надо убивать.

Если целевой язык и его stdlibs поддерживают - то да.

Attoparsec умеет возвращать продолжение при конце ввода, потом можно подгрузить в буфер новых данных и продолжить парсинг. Незаменимо, когда объём данных идёт на гигабайты и более. Тут проблема не в stdlibs языка, а в логике самого парсера.

good_riddance
()
Ответ на: комментарий от GreyCat

Не очень понял вопрос - что значит «плотно упакованы»? Если нужно побитовое unaligned чтение - то это есть feature requests про bitfields и про возможность менять alignment, в том числе с точностью до бита.

Да, всё это нужно, в том числе. Под «упаковкой» я имел в виду случаи, когда целые с размером, отличным от 8 или 16 идут друг за другом без выравнивания и дополнения до границ байта.

value: '(tmp & 0b1111111111110000) >> 4'

Я просто не нашёл в описании языка операторов & и >>, но если всё это есть, то отлично.

Инструмент хороший задуман, декларативность привлекает.

DronK
()
Ответ на: комментарий от good_riddance

Fail, есть бинарные форматы где это нужно. К сожалению. Да, за такое надо убивать.

Я такой пока знаю примерно один - формат bencoded, он же формат .torrent. Но назвать его бинарным форматом с трудом язык поворачивается.

Attoparsec умеет возвращать продолжение при конце ввода, потом можно подгрузить в буфер новых данных и продолжить парсинг. Незаменимо, когда объём данных идёт на гигабайты и более. Тут проблема не в stdlibs языка, а в логике самого парсера.

А, вы про такое. Я бы не называл это буферизацией - это скорее всякие pub/sub, producer/consumer и т.д. У нас висит подобный вопрос для обсуждения по поводу продолжения парсинга неполных данных: т.е. когда идет поток сетевого трафика, обрезанный на середине пакета и нужно уметь восстановиться после обнаружения того, что очередной пакет распарсить пока нельзя. Готового решения нет.

Впрочем, если вас волнует только парсинг гигабайтов валидных данных с диска, например - я не вижу проблем, адекватную загрузку их в память как раз обеспечат ОС (например, mmap'ом) и stdlibs.

GreyCat ★★
() автор топика
Ответ на: комментарий от DronK

Я просто не нашёл в описании языка операторов & и >>, но если всё это есть, то отлично.

Все есть, на самом деле язык выражений достаточно мощный, а вот документации по нему катастрофически не хватает. Пока висит заглушка.

GreyCat ★★
() автор топика

а затем с помощью предлагаемого компилятора транслируется в исходный код парсинга (на данный момент поддерживаются C#, Java, JavaScript, Python, Ruby и предварительно — C++).

А не думали ли вы использовать Ragel https://www.colm.net/open-source/ragel/ ? Т.е. создавать описание конечного автомата, и потом его передавать в ragel

SZT ★★★★★
()

Я вот только не понял, это какая-то «серебрянная пуля», парсящая априори все, или просто достаточно большой набор парсеров популярных способов кодировки?

segfault ★★★★★
()
Ответ на: комментарий от SZT

Насколько я вижу - Ragel - это плюс-минус очередной парсер-генератор для _регулярных_ языков, только генерирующий код парсера на основе конечного автомата. Этот класс ПО выполняет кучу интересных функций типа уже упомянутого тут бэктрекинга и контроля неоднозначных ситуаций: когда есть очередная "(" на входе и исходя из только одной этой скобочки нельзя определить, что это - скобки, обрамляющие вызов функции, скобки для изменения порядка вычисления арифметического выражения или что-то еще. Инструментов этого класса на самом деле масса, но для парсинга бинарных форматов, как правило, в жизни пользоваться ими довольно неудобно: их сложно отлаживать, даже для простейших форматов зачастую описание грамматики становится чудовищно большим и т.д. и т.п.

Kaitai Struct - скорее «конкурент» таких вещей, как Construct, Preon, binpac и т.д.

GreyCat ★★
() автор топика
Ответ на: комментарий от segfault

Я вот только не понял, это какая-то «серебрянная пуля», парсящая априори все, или просто достаточно большой набор парсеров популярных способов кодировки?

Это что-то среднее. Исходный посыл очень простой: бинарные форматы разрабатываются ровно для того, чтобы их было легко и удобно читать и писать из программы. И приемов такого легкого чтения-записи на самом деле не так много - мы и пытаемся их выписать и реализовать на всех поддерживаемых языках программирования.

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

GreyCat ★★
() автор топика
Ответ на: комментарий от Deleted

Понятно, сейчас подумаю, как сделать понятнее. Есть, может, какие-то хорошие примеры сайтов библиотек/фреймворков, где все прямо кристально понятно, бросается в глаза и все такое? Откуда идеи можно почерпнуть?

GreyCat ★★
() автор топика
Ответ на: комментарий от GreyCat

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

Гугл использует ragel как раз для работы с бинарными данными. Например, валидатор для опкодов x86_32 и x86_64 для NaCl сандбокса:

https://chromium.googlesource.com/native_client/src/native_client/ /master/sr... https://chromium.googlesource.com/native_client/src/native_client/ /master/sr...

и сгенерированный сишный код:

https://src.chromium.org/viewvc/native_client/trunk/src/native_client/src/tru... https://src.chromium.org/viewvc/native_client/trunk/src/native_client/src/tru...

Это все делается для того, чтобы не позволить дергать системные вызовы ОС, чтобы кто-нибудь не прыгнул в середину опкода итд. Так что с помощью ragel эти задачи решают. Код там кстати получается на чистом Си (я кстати не совсем понимаю Релиз Kaitai Struct v0.4 (комментарий) о чем там можно не договориться? Делайте конечный автомат и разбираете им последовательно поток байтов. В чем проблема?)

SZT ★★★★★
()

А поля переменной длины без явного указания таковой — поддерживаются? Например Rar'овский vint?

Ну и отдельно, планируется ли поддержка Lua?

Quote
()
Ответ на: комментарий от SZT

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

Задачи, решаемые инструментами вроде KS, Preon, binpac, Construct, DFDL и т.д. - другие. Конечно, и то, и то можно свести к тьюринг-полноте и что и то, и то можно реализовать с помощью некоей абстрактной модельной машины. Но зачем?

GreyCat ★★
() автор топика
Ответ на: комментарий от Quote

А поля переменной длины без явного указания таковой — поддерживаются? Например Rar'овский vint?

Да, но весьма вручную. Пишется конструкция типа такой:

types:
  varint:
    seq:
      - id: b1
        type: u1
      - id: b2
        type: u1
        if: 'b1 & 0x80 != 0'
    instances:
      result:
        value: '(b1 & 0x80 == 0) ? b1 : ((b1 & 0x7f) + (b2 << 7))

... ну, можете себе представить во что это превращается для полноценного 10-байтового varint. С введенем unaligned bit reading должно по идее стать полегче.

Ну и отдельно, планируется ли поддержка Lua?

Пока никто не просил, теоретически сделать должно быть несложно.

GreyCat ★★
() автор топика
Ответ на: комментарий от GreyCat

Вы в памяти вообще ничего переменного не храните и не копите, кроме текущего состояния, прыгаете по таблице переходов FSM и ответ по сути бинарный - «прошел / не прошел валидацию».

Пример из валидатора NaCl это частный случай. По факту же, никто и ничто не мешает написать через этот ragel дизассемблер, например. Или использовать его для разбора ethernet фреймов и прочих протоколов. Чем-то подобным занимается vromanov насколько я понял:

Получить значение поля структуры Код для чтения хитрых полей

так что ему возможно будет полезен Kaitai Struct, ragel и прочие упомянутые (Preon, binpac, Construct, DFDL)

Задачи, решаемые инструментами вроде KS, Preon, binpac, Construct, DFDL и т.д. - другие.

В чем же они другие? Через ragel решаемы все задачи, которые решаются этими «другими» инструментами. Может быть они могут выдать более оптимальное решение, чем инструмент более общего назначения (типа ragel)?

Кстати есть еще ASN.1 компиляторы, например https://directory.fsf.org/wiki/SNACC

SZT ★★★★★
()
Ответ на: комментарий от SZT

«Общность» задач, о которой вы говорите, сводится к тому, что и то, и то - более-менее turing-complete механзимы, которыми можно сделать любое преобразование. На этом по сути сходство заканчивается. Если вам надо загрузить в память, скажем, png-формат и отобразить картинку на экране - по-моему, использовать для этого FSM как-то глупо. Да, можно описать тучу состояний типа «начали читать» -> «читаем заголовок» -> «читаем первое поле заголовка» -> «между первым и вторым полем» -> ... - и вручную дописать для каждого из состояний код, который будет делать какое-то действие - например, выводить картинку на экран - но зачем? Тот же libpng, скажем, предлагает куда более общий и удобный для программирования API. А KS по сути позволяет делать то же самое, что libpng.

Кстати есть еще ASN.1 компиляторы, например https://directory.fsf.org/wiki/SNACC

То, что вы показали - ASN.1 BER - по сути ничем не отличается от постоянно вспоминаемых при обсуждении KS штук типа protobuf, Apache Thrift, Avro и т.д. Это способ описать структуру данных, а не их сериализацию. С его помощью не прочитаешь произвольный формат. В стандартах ASN.1 есть на самом деле секция описания произвольных бинарных форматов (но это не BER), но это такой взрыв мозга, что я ни разу не видел, чтобы его кто-то серьезно пытался использовать.

GreyCat ★★
() автор топика
Ответ на: комментарий от SZT

Ты не мог бы четко объяснить, каковы преимущества парсинга с использование Ragel перед парсингом с использованием Kaitai (или Construct)? А то со стороны выглядит, как будто ты лезешь с непрошеными советами к людям, которые имеют солидный опыт работы в определенной предметной области.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)

Если оно умеет визуализатор, то может есть какие-то средства для ковыряния непонятных форматов, например, старых досовских игр? Ну и пример, на чем-то простом, как распарсить, к примеру, mp3 или avi?

ruzisufaka
()
Ответ на: комментарий от tailgunner

Чем лучше - тем что Ragel это инструмент более общего назначения. Ragel используется для лексического разбора в языке Jancy http://tibbo.com/jancy/compiler.html

У меня встречный вопрос: зачем создавать узкоспециализированные инструменты (вроде Kaitai) когда есть инструменты более общего назначения, вроде Ragel и всяких других лексеров-парсеров, используя которые можно решать те же самые задачи и даже больше? В чем у KS преимущество? Может быть есть какие-нибудь сравнения кода, сгенерированного через KS и через Ragel для разбора какого-то бинарного формата, сравнения «понятности» кода написанного на ragel с кодом из KS (.ksy format) и скорости разбора. Вот это было бы интересно, было бы о чем поговорить.

SZT ★★★★★
()
Последнее исправление: SZT (всего исправлений: 2)
Ответ на: комментарий от SZT

Чем лучше - тем что Ragel это инструмент более общего назначения.

И почему это лучше? Еще раз: решаемая задача - это разбор форматов данных. Что заставило тебя подумать, что Ragel для этого подходит лучше, чем Kaitai?

У меня встречный вопрос: зачем создавать узкоспециализированные инструменты (вроде Kaitai) когда есть инструменты более общего назначения, вроде Ragel и всяких других лексеров-парсеров, используя которые можно решать те же самые задачи и даже больше?

Вероятно, затем, что задачу разбора двоичных форматов Kaitai решает с гораздо меньшими затратами. Если ты считаешь, что затраты при использовании Ragel сравнимы или меньше, обоснуй свои слова.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

И почему это лучше? Еще раз: решаемая задача - это разбор форматов данных.

Фоматы данных бывают разными. Пригоден ли KS для разбора XML например(с вложенными друг в друга тегами, вот этим всем)? Если будут возражения насчет текстовой природы этого формата, можно взять binary XML (хотя любой текст это тоже по сути бинарные данные).

Что заставило тебя подумать, что Ragel для этого подходит лучше, чем Kaitai?

Меня ничего не заставляло. Я просто изучал исходники валидатора опкодов из-под NaCl сандбокса, и увидел, что там используется как раз этот Ragel. Kaitai на момент написания того кода кстати не существовало, так что это ни разу не аргумент в пользу того, что что-то из этого хуже, а что-то лучше, но Ragel для этого МОЖНО использовать.

Вероятно, затем, что задачу разбора двоичных форматов Kaitai решает с гораздо меньшими затратами

Затратами в каком смысле? Разбор двоичных форматов быстрее будет работать? Или может сам код быстрее писать для KS чем для генератора FSM. Хотелось бы услышать некие аргументы

Если ты считаешь, что затраты при использовании Ragel сравнимы или меньше, обоснуй свои слова.

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

SZT ★★★★★
()
Последнее исправление: SZT (всего исправлений: 2)
Ответ на: комментарий от SZT

Пригоден ли KS для разбора XML например(с вложенными друг в друга тегами, вот этим всем)?

А чего только тегами? Давай уже и неймспейсы, и схемы. И нет, Kaitai не предназначен для разбора XML.

Вероятно, затем, что задачу разбора двоичных форматов Kaitai решает с гораздо меньшими затратами

Затратами в каком смысле?

Затратами труда.

Или может сам код быстрее писать для KS чем для генератора FSM. Хотелось бы услышать некие аргументы

И правда. На главной странице сайта Kaitai приведено описание GIF в ksy. Начни с того, что приведи аналогичное описание на Ragel.

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

То есть ты просто не понимаешь, зачем нужен Kaitai, если есть Ragel. Ну окей.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от GreyCat

Вообще, инструмент очень интересный, спасибо вам за него. :)

Смущают пока разрозненная документация и референсный компилятор на Scala либо альтернатива в виде JavaScript в браузере. Право же, встраиваемая библиотечка на C99/C11, которая сама же и собирается в консольный бинарь — была бы полезнее. Да хотя бы самодостаточный скрипт на perl/python/(или Lua, ага :D). Требовать JRE либо JS–движок для реверсерских тулз это же ужас–ужас.

Ну, и ручной bit–twiddling тоже не радует. Было желание применить для потрошения бинарников, сжатых мешаниной из LZ77, deflate и ещё непойми чего, но, судя по всему, средствами одного лишь KS это пока тяжко.

С введенем unaligned bit reading должно по идее стать полегче.

Ждём, и ждём с нетерпением. Тоже попадалась задача парсить поток десятибитных данных, записанных в восьмибитном формате, упомянутая DronK.

Кстати, если кто–то ещё впечатлился, на ресурсе–который–нельзя–называть есть вполне популярно написанная статья о практическом применении KS.

Quote
()
Ответ на: комментарий от ruzisufaka

Если оно умеет визуализатор, то может есть какие-то средства для ковыряния непонятных форматов, например, старых досовских игр?

Да вот вроде бы KS и предлагается в том числе как такое «средство».

Ну и пример, на чем-то простом, как распарсить, к примеру, mp3 или avi?

Я сильно сомневаюсь, что mp3 или avi - это «что-то простое». Есть репозитарий с коллекцией примеров - пойдет?

GreyCat ★★
() автор топика
Ответ на: комментарий от tailgunner

То есть ты просто не понимаешь, зачем нужен Kaitai, если есть Ragel. Ну окей.

Пока аргументация SZT сводится примерно к тому, что и то, и то - более-менее тьюринг полное. И там, и там можно написать какую угодно программу. Примерно так же какую угодно программу можно написать и на голом C, и в голых машинных кодах какого-нибудь процессора, и для абстрактных Mealy / Moore автоматов. Ну, можно. Дальше-то что?

GreyCat ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.