Re: fun (not so much) with funopen

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Bad idea.  funopen() needs to be a wrapper around something with the
> new functionality.

That's possible only if the wrapper is part of stdio, because fpos_t is
too opaque.

> And, as long as you are doing that, it makes *MUCH* more sense to go
> with an interface that takes a ops structure:

Like the Linux one.  Hmm, @gnu.org...coincidence? :-)

Please, no.  I've written glue to run code designed for funopen() using
fopencookie; while I haven't written it, I've sketched out how to do
the converse.  Implementing funopen with fopencookie is annoying (it
costs an extra malloc on stream open, free on close, and one more
function call for each method operation on the stream); the converse is
trivial.  Which way is easier to write glue for is a fairly clear
indication which interface is preferable.

>> What do you think?
> If you're going to break something, then go whole hog and fix it so
> you won't have to break the API ever again. :)

How does an ops struct do that?  You still have an API flag day
whenever you change the ops struct, which is just a somewhat obscured,
inconvenient, and textually separate version of the arglist to funopen.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B