А почему си забыли?

Или «нинужна»?

С си они никак не могут определиться с тем, какой лучше генерировать код.

Обсуждалось в прошлый раз. Видимо, к концептуальной договорённости ещё не пришли.

Для концептуальной договоренности неплохо бы найти хотя бы один реально заинтересованный проект :) Пока почему-то на C++ я знаю около десятка реальных пользователей, на Java - тоже, а вот про C почему-то пока в основном разговоры.

C++, C#, Java, JavaScript, Perl, PHP, Python, Ruby

Как нет хачкеля??

Это, очевидно, потому что кайтай - подмножество хаскеля.

Надо просто несколько разных генераторов запилить с разными подходами.

Очередной велосипед по стандартизации 14 предыдущих стандартов :) JSON им мало - это же NIH!

Написан на Скале О_о

Да вот только пилить генераторы в воздух как-то не хочется. Это не так быстро, а от всяких реквестов и так трекер ломится. Лучше делать что-нибудь востребованное, не?

Можно полюбопытствовать, какое отношение имеет JSON к топику?

ты вообще читал о чем этот софт ?

JSON? Что ты несешь... А, норм, это матумба.

Это чтобы что?

Звучит очень круто.

Насколько оно готово для продакшена. Насколько это можно безопасно использовать. Допустим, мне нужно описать формат транзакций Bitcoin. Какова вероятность отстрелить себе ногу из-за ошибки в самом Kaitai Struct, или что сломают совместимость.

Следует ли его применять, когда нужно описать бинарный формат один раз, и уже наверняка знать, что сможешь его применять неограниченное время в дальнейшем, и что ничего не сломается? Как разработчики позиционируют проект, как экспериментальный, или как готовый к применению?

А может kaitai обойтись без std::ifstream, допустим указателем на uint8_t и размером данных? Можно ли узнать минимальный размер необходимых данных для желаемого типа?

uint32_t minSize = kaitai::getMinSize(git_t);
// load data in to memory const uint8_t* data; uint32_t minSize;
kaitai::kstream ks(data, minSize);
gif_t g = gif_t(&ks);
if (g.isDataValid())
{
   // bingo!
}
else
{
   // try another format
}

Навороты нехилые, но применимость на практике так себе. При разборе формата, особенно если спека отсутствует, описать формализмрованным языком будет сложно.

Навороты нехилые, но применимость на практике так себе.

Практики бывают разные. Я, прочитав эту новость, сразу подумал о использовании kaitai в своем вьювере.

Шо тока не придумают, чтоб бинарные логи в systemd на человекочитаемые не менять.

просто до кучи, к древней ссылке на III ASN.1 в прошлом треде, еще вспомнил забавный проект http://gentle.compilertools.net/book/preface2005.html

Насколько оно готово для продакшена

Несколько десятков проектов используют.

Допустим, мне нужно описать формат транзакций Bitcoin

Он вроде бы совсем примитивный, кто-то вроде уже что-то такое заявлял, что делает...

Какова вероятность отстрелить себе ногу из-за ошибки в самом Kaitai Struct, или что сломают совместимость.

Вероятность всегда и везде есть, вопрос в цене ошибки. Если нужны гарантии и SLA - сами знаете, оформляется договор и вот они - гарантии.

Как разработчики позиционируют проект, как экспериментальный, или как готовый к применению?

До 1.0 может незначительно меняться API и явно будут ужесточаться проверки, которые делает компилятор, но если не делать каких-то совсем странных вещей, вряд ли это будет сильно актуально в обычных проектах.

А может kaitai обойтись без std::ifstream, допустим указателем на uint8_t и размером данных?

std::ifstream совсем не обязателен, там std::istream. Указатель и размер всегда можно обернуть в какой-нибудь std::istringstream - и вперед.

Можно ли узнать минимальный размер необходимых данных для желаемого типа?

Пока нет и, честно говоря, не очень представляю, зачем это нужно. Через какое-то время будет можно узнать что-то типа sizeof() по отдельным типам - но, опять же, не факт, что это будет выведено на уровень целевого языка, а не останется оператором языка выражений внутри KS.

При разборе формата, особенно если спека отсутствует, описать формализмрованным языком будет сложно.

Оно, собственно, как раз в основном для разбора неизвестных форматов и писалось. В итоге (особенно наличие инструментов визуализации) сильно быстрее разбирать, чем сначала писать на каком-нибудь скриптовом языке дампер, а потом переписывать еще раз на «взрослых» C++ / Java, попутно придумывая структуры, в которые это в памяти все разложить.

Вот даже что, мне важна именно однозначность соответствия бинарного формата, формальному описанию на языке Kaitai Struct. Чтобы соответствие оставалось точно таким-же в будущих релизах. Насколько можно рассчитывать на обратную совместимость такого рода? Стабильность API не критично, в данном случае.

Указатель и размер всегда можно обернуть в какой-нибудь std::istringstream - и вперед.

Лишняя обертка над указателем в памяти и размером.

Можно ли узнать минимальный размер необходимых данных для желаемого типа?

Пока нет и, честно говоря, не очень представляю, зачем это нужно.

Для того, что бы прочитать из файла только минимально необходимый для данного формата набор данных.

Я думаю, что ничего критично уже не сломаем. Я не очень представляю, что должно произойти с проектом, чтобы, скажем, `type: u1` внезапно стало обозначать что-то отличное от «один байт unsigned integer», которое оно обозначает сейчас. В конце концов - у народа, наверное, есть уже несколько сотен .ksy и я не думаю, что ломать что-то в семантике сейчас реально.

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

Лишняя обертка над указателем в памяти и размером.

Весь C++ - это сплошные обертки. В данном случае, как мне кажется, мы поступаем вполне себе C++ way. Я, собственно, не очень представляю, чтобы в современном C++ голые указатели кто-то использовал.

Для того, что бы прочитать из файла только минимально необходимый для данного формата набор данных.

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

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

Я не очень представляю, что должно произойти с проектом, чтобы, скажем, `type: u1` внезапно стало обозначать что-то отличное от «один байт unsigned integer», которое оно обозначает сейчас.

Спасибо, я тоже думаю, что излишнее беспокойство.

Надо просто несколько разных генераторов запилить с разными подходами.

Т.е. проделать в разы больше работы при полном отсутствии потребности в поддержке C.

Я, прочитав эту новость, сразу подумал о использовании kaitai в своем вьювере.

Тащить Java для сборки приложения на плюсах? Или один раз сгенерировать парсер и никогда больше не запускать генератор?

IMHO для парсера на плюсах имеет смысл посмотреть на Ragel. Хотя, он не такой функциональный, конечно.

Оно, собственно, как раз в основном для разбора неизвестных форматов и писалось.

Интересно. А планируется ли сделать что-нибудь для поддержки шифрованных форматов?

Какова вероятность отстрелить себе ногу из-за ошибки в самом Kaitai Struct

нулевая,весь код банален донельзя,чтения по адресу/смещению никак не могут «отстрелить» что либо,физически невозможно

Или один раз сгенерировать парсер и никогда больше не запускать генератор?

Именно так.

Думать - это одно, а реально использовать - совсем другое.

В итоге (особенно наличие инструментов визуализации) сильно быстрее разбирать, чем сначала писать на каком-нибудь скриптовом языке дампер, а потом переписывать еще раз...

Писание на KSY не считается? :) Ничем не лучше дампера на скриптовом языке. Кроме того, от разбора формата это не освобождает. Даже если KSY файл наваял кто-то, в потрохах формата все-равно нужно разбираться. Иначе не оттранслируешь во внутреннюю модель своей аппликухи.

В целом, если надо разово обращаться к теме разбора и, особенно, если есть готовый KSY файл, сабж имеет смысл применять.

Если есть потребность в разработке импортеров/экспортеров N-го кол-ва - выгоднее в архитектуре аппликухи предусмотреть возможность визуализации и анализа данных и наваять соотв. фронтенд для этого (благо он не сложный). Потому как в таком случае и парсеры пишутся «по живому», сразу в проект, и контролировать работу аппликухи это позволяет и трансляцию из распарсенного в во внутреннюю модель.

Или один раз сгенерировать парсер и никогда больше не запускать генератор?

Именно так.

Это верно в случае простых и кондовых форматов, разбор которых выполнен на все 100%. На практике, даже простейший BMP может поддерживаться не во всех версиях. И возвращаться придется несколько раз на перегенерацию. А более сложные проприетарные форматы (аля PSD), которые меняются с каждой новой версией - с ними ваще неразлучно жить с KSY файлами.

нулевая,весь код банален донельзя,чтения по адресу/смещению никак не могут «отстрелить» что либо,физически невозможно

Более чем возможно. Любые неясности в Kaitai или в разбираемом формате - изменения в адресах/смещениях и огрести сегфолт или эксепшн как два пальца об асфальт :)

и чем страшен сегфолт?

банально можно подменить любой конфиг в линуксе на бинарный мусор-будет сегфолт

вопрос был не про КАК отстрелить/убить программу

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

BTW в разборе WMF лучше на MSDN ссылаться:

https://msdn.microsoft.com/en-us/library/cc250372.aspx

а не на third-party описание. Всетки ближе к церкве :) И имена WMF Records лучше в оригинальном camelcase как в MSDN, ИМХО.

А более сложные проприетарные форматы (аля PSD), которые меняются с каждой новой версией - с ними ваще неразлучно жить с KSY файлами.

все верно

вот так-добавляют по полю в начало структуры каждую новую версию PSD(к примеру) и ты просто добавляешь тожесамое в свой шаблон KSY и генериш либу и работаешь сразу с данными,ибо имена(переменных внутри либы твоей) то старых данных не изменились

либо ты имеешь секас со смещениями в Си и каждый раз при обновлении пересчитываешь ручками все смещения переписываешь структуру меняешь кучу банальных циклов чтения по адресу

выбирай

«Мы пошли другим путем!» (с) :)

https://sk1project.net/viewpage.php?page_id=23

Выше я описал принцип работы.

дытэктор мышкоюзера зашкалил

кто вас пустил писать код?

Писание на KSY не считается? :) Ничем не лучше дампера на скриптовом языке.

По-моему - лучше. Собственно, весь KS и вырос ровно из того, что мне надоело в пятнадцатый раз писать примерно одно и то же в дампере, еще и зная, что весь этот код придется выкинуть, а после этого еще писать совершенно скучную документацию и рисовать таблички для сотрудников, а потом еще и написать все то же самое на C++.

Там, где на скриптовом языке надо писать по 2-3 длинных строчки, вставляя кучу отладки, на KS достаточно зачастую одной. Отладку и дампинг вставлять тоже не нужно, визуализатор покажет все в разы удобнее, чем может весьма коряво отобразить дампер.

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

А потом в один прекрасный момент все съезжает на один байт и начинается обвешивание этого решения тучей отладки, здесь вывести смещение, здесь подампить сколько-то в hex, здесь еще какие-то условные обозначения придумаем, чтобы в этом потоке на несколько мегабайт что-то глазами можно было найти - и пошло-поехало.

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

Таки-нинужна. Сишники описывают структуры сразу на С и на морочат себе голову парсерами.

BTW в разборе WMF лучше на MSDN ссылаться:

Спасибо, сошлемся. У нас скоро будет еще специальное поле doc-ref - как раз, чтобы ссылаться.

И имена WMF Records лучше в оригинальном camelcase как в MSDN, ИМХО.

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

На самом деле истина где-то посередине. Я вполне понимаю, что когда работаешь с графическими форматами - зачастую что-то (координаты, например) удобно сразу в приложении смотреть.

Как я уже указывал выше, для отладки мы используем отдельное приложение (https://sk1project.net/viewpage.php?page_id=23), которое очень похоже по функционалу на визуализатор KSY. А контроль результата в векторном редакторе - это уже конечная валидация.

Таки-нинужна. Сишники описывают структуры сразу на С и на морочат себе голову парсерами.

все врерно,на 1 курсе института так и делают,а что дальше?

они начинают писать на джаваскрипте?

Таки-нинужна. Сишники описывают структуры сразу на С и на морочат себе голову парсерами.

Ога. А потом огребают проблемы с endianness, byte alignment, #pragma pack, сегфолты и непонятно откуда-то взявшиеся тормоза при обращении к структуре.