tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: fun (not so much) with funopen

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.

Home | Main Index | Thread Index | Old Index