[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.

Attachment: pgp6eB_K8wEJr.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]