[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new module 'freadptr'
From: |
Eric Blake |
Subject: |
Re: new module 'freadptr' |
Date: |
Fri, 29 Feb 2008 00:22:13 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
Bruno Haible <bruno <at> clisp.org> writes:
>
> Hi,
>
> Here's one more module in the "stdio internals" series. freadptr (stream)
> returns a pointer to the read buffer of stream.
Nice idea - I can already envision using it in M4 (more on that on the m4-
patches list in response to your recent proposed patch for speeding up M4's
string delimiter hunting by searching a buffer rather than a byte at a time).
> size_t available = freadahead (fp);
> if (available > 0)
> {
> const char *buf = freadptr (fp);
So based on your API documentation change, this needs to check for NULL.
> const char *nl = (const char *) memchr (buf, '\n', n);
> if (nl != NULL)
> {
> obstack_grow (obs, buf, nl - buf);
> fseek (fp, nl - buf + 1, SEEK_CUR);
Not safe on pipes. If fp is seekable, then this is okay. But if not, then
you'll have to actually do the fread(fp,1, nl-buf+1, <some buf>) to keep the
stdio stream in sync with what you copied into the obstack. You could consider
using obstack_room, and if large enough, do the fread directly into
obstack_next_free, then follow up with obstack_blank_fast to get the obstack to
recognize that you grew its contents on the side; otherwise do the fread into a
temp buffer and obstack_copy it into the obstack which will grow
appropriately. I did something similar to this in m4's format.c for
implementing my poor-man's obstack_printf with no extra data movement when the
obstack had enough room.
--
Eric Blake