Re: fun (not so much) with funopen

[Bruce Korb <bkorb%gnu.org@localhost>]

On 03/16/12 09:56, Mouse wrote:
> Agreed.  To me this is a more minor annoyance, but still an annoyance.
> I'll even put up with the annoyance of having to fix all my own funopen
> code to adopt this change.  (A few more tweaks to my private source
> trees is no big deal.)
>
> > What do you think?
>
> I think these are good changes that have needed making for a long time.

I actually have a project out there that will choke and die with this change.
Since stuff that is "out there" hangs around for years on end, I will
undoubtedly get bug reports trickling in for years while some folks update
their BSD without updating my project.  *PLEASE* consider a rename and
compatibility wrapper.  Changing APIs is a painful process not to be taken
lightly.  Thank you!

Regards, Bruce

P.S. there's also this:

> POSIX2008 require open_w?memstream(3), but our stdio doesn't have
> chance to override FILE fflush handle.
> so it is hard to implement it. (and our fmemopen(3) implementation
> have bug related about this).
>
> i need read/write/seek/close/flush override point, but i don' t think
> funopen(3) is for it.
> funopen(3) is used by 3rd party application(such as tcsh), impact is
> not small, i think.
> (fpos_t -> off_t change breaks API, but still keep ABI, and tiny macro
> may be the salvation).
>
> i think we supply new library function or syscall is better.

which really ought to be handled with a perturbed API anyway.