Flex-буфер хранит часть ввода вместе с достаточным количеством информации для продолжения обработки ввода. Вам не нужно беспокоиться о том, сколько входных данных есть.
Оригинальный сканер lex не буферизовался. Он просто читает ввод по одному символу за раз, собирая текущий токен в массив символов yytext. Это работало хорошо, когда токены были не слишком большими, но это не самое эффективное решение. Так что flex пытается ускорить сканирование, считывая буфер данных за раз. Flex также избегает необходимости копировать каждый токен, просто используя данные непосредственно из буфера; в flex * yytext является указателем на буфер, а не отдельным массивом.
В дополнение к ускорению обработки ввода, Flex-буферы предоставляют вам ряд дополнительных функций, в том числе возможность предоставлять буферы памяти и стек буфера, полезные для обработки таких вещей, как директивы #include.
Единственное ограничение памяти - это размер токена. Каждый токен должен помещаться в памяти во время его обработки. Когда сканирование шаблона достигнет конца буфера, flex сначала сместит токен в начало буфера, а затем при необходимости попытается изменить размер буфера.
Размер, который вы указываете при вызове yy_create_buffer, - это начальный размер буфера, а не его предел. Столкнувшись с огромным токеном, flex продолжит расширять буфер, если это необходимо, до тех пор, пока не произойдет сбой выделения памяти. Очевидно, что теоретически возможно иметь токен настолько большой, что это невозможно. Поэтому не используйте шаблон, подобный (.|\n)+, если вы ожидаете, что ваши входные потоки будут содержать петабайты данных. : -)
В оригинальном lex yytext был массив, а не указатель, изменение размера было невозможно, а размер массива во время компиляции устанавливал фиксированное ограничение на длину токена. Flex является улучшением в этом отношении, но он не оптимизирован для больших токенов, и есть некоторые проблемы с производительностью, когда ваше приложение пытается обработать мегабайты данных как один токен.