[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-recutils] Seekable parsers
From: |
Michał Masłowski |
Subject: |
Re: [bug-recutils] Seekable parsers |
Date: |
Thu, 24 May 2012 22:22:12 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
> If we use mmap to read the recfile, parsers would need an additional
> interface to not read past the end of the file, e.g. like this one:
>
> /* Create a parser associated with a given buffer that will be used as
> the source for the tokens. The buffer is of specified size and
> doesn't have to be null-terminated. If not enough memory, return
> NULL. */
>
> rec_parser_t rec_parser_new_mem (const char *buffer, size_t size,
> const char *source);
>
> That is ok. But since the special case where SOURCE is NULL-terminated
> can be easily handled using strlen (source) as the SIZE argument, I
> would not introduce a new function. Just rename rec_parser_new_str into
> rec_parser_new_mem.
Checking that seek positions fit in the buffer would also use the size,
so knowing it would be useful also with NULL-terminated buffers. This
change would also make less tests needed than adding a separate backend.
> But then, is using mmap the best option here? An alternative would be
> to expand the fopen-based parser backend in order to use fseek/ftell.
> The FILE* functions have less portability issues that mmap, and the
> parser is character-oriented anyway.
Using mmap could be faster, this should be easy to measure later, so
I'll expand the file backend instead.
pgp6eB_K8wEJr.pgp
Description: PGP signature