OberonCore

Согласен. Просто мне кажется, что врят ли конечный юзер парсера станет подгонять их под свои файлы...

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

Речь о том, что буфер не есть один массив, а состоит из кусков-массивов определенной длины. У Ивана каждая "строка" хранит размер куска как поле, а все реальные и потенциальные куски перечисляются в ARRAY OF POINTER TO ARRAY OF CHAR, который переразмещается и растет кусками другого размера (тоже поле).

Если эти размеры кусков не хранить в полях каждой "строки", а зафиксировать, процедура доступа с символу упрощается.

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

О том самом. В моём варианте есть возможность выбирать размер "скачка" для каждого буфера, а если задать этот размер жёстко - компилятор слегка пооптимизирует.