Re: [RFA] ui-file.[ch]: tell(), mem_filebuf()

[Andrew Cagney <ac131313 at cygnus dot com>]

Nick Duffek wrote:
> 
> On 15-Dec-2000, Andrew Cagney wrote:
> 
> >>   1. Adds a tell method to the ui_file interface.
> 
> >Um, it might be useful if you expanded a little on what you're trying to
> >do and why it isn't currently possible.
> 
> What I'm trying to do: add a tell() method analogous to ftell() that
> returns the current position in a ui_file.
> 
> Why it isn't currently possible: because there isn't a ui_file tell
> method.  Right now we have isatty, write, fputs, flush, delete, rewind,
> and put.
> 
> I forget why I needed it, because in fact I don't use it now.  But it
> provides an obvious missing piece in the file abstraction provided by
> ui_file, so I'm posting it in case it's needed by someone else in the
> future.

Your right that the names were chosen so that people would recognize
them and their intended semantics.
However, ui_file isn't trying to emulate the entire f*() library. 
Unless there is a really good reason to add ftell() I don't think it
should be added.

> >>   3. Defines a new function, char *mem_filebuf (struct ui_file *file), to
> >>      return the buffer currently used for storing FILE's contents.
> 
> >Is it a good idea to expose the internal workings of a specific ui_file
> >implementation?
> 
> It doesn't expose the internal workings of anything.  It simply adds a
> memory-file method returning a read-only buffer that needn't be freed
> by the caller and that takes O(1) time to create.

Long ago there was this tui_file like beastie that ui_file was largely
based on.  One of tui_file's features was that it allowed access to the
raw buffer (see *_strbuf()).  In adding the mem_file object it was
decided that the direct hacking on the internal raw buffer would be
replaced by the two methods rewind() and xstrdup().  Both of these
methods were atomic and didn't reveal internals.

Does your code really have a performance problem serious enough to
justify direct access to the internal buffer?

If a pointer to the internal buffer was returned, what would the
lifetime of that buffer be?  Until the next ui_* call or some
later/earlier/arbitrary time?  While _*xstrdup() might be O(N) it avoids
those problems.

> In object-oriented parlance, the memory ui_file class is derived from the
> null ui_file class.  There's nothing unusual about derived classes having
> extra methods that wouldn't make sense in their base classes.

	enjoy,
		Andrew