[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

reply via email to

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