Re: fun (not so much) with funopen

[Takehiko NOZAKI <takehiko.nozaki%gmail.com@localhost>]

hi,

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.

very truly yours.
--
Takehiko NOZAKI<takehiko.nozaki%gmail.com@localhost>


2012/3/17 Christos Zoulas <christos%zoulas.com@localhost>:
>
> Hello,
>
> As some of you might have noted, recently we changed the API/ABI of funopen(3)
> from:
>
>        FILE    *funopen(const void *cookie,
>            int (*readf)(void *cookie, char *buf, int len),
>            int (*writef)(void *cookie, const char *buf, int len),
>            fpos_t (*seekf)(void *cookie, fpos_t offs, int whence),
>
> to:
>
>        FILE    *funopen(const void *cookie,
>            int (*readf)(void *cookie, char *buf, int len),
>            int (*writef)(void *cookie, const char *buf, int len),
>            off_t (*seekf)(void *cookie, off_t offs, int whence),
>            int (*closef)(void *cookie));
>            int (*closef)(void *cookie));
>
> This change broke both binary and source compatibility with the previous
> version, but was necessary since fpos_t is an opaque type used only by
> fgetpos(3) and fsetpos(3), and programs using funopen(3) resorted in
> ugly games with its guts to make funopen(3) to work properly. It would
> be nice if other BSD's followed suit if/when their fpos_t is not off_t.
>
> Since this change is still fresh, I suggest that we go one step further and
> change the signature to be more in accordance with the standard read(2) and
> write(2) system calls:
>
>        FILE    *funopen(const void *cookie,
>            ssize_t (*readf)(void *cookie, void *buf, size_t len),
>            ssize_t (*writef)(void *cookie, const void *buf, size_t len),
>            off_t (*seekf)(void *cookie, off_t offs, int whence),
>            int (*closef)(void *cookie));
>            int (*closef)(void *cookie));
>
> The reason to do this, is so that we can make the internal stdio read and
> write functions match better with the system calls they actually use.
> I am planning use the standard rename process to maintain binary compatibility
> with the previous version of the function...
>
> What do you think?
>
> The alternative would be to supply a funopen2() system call with the proposed
> signature.
>
> christos



-- 
Takehiko NOZAKI<takehiko.nozaki%gmail.com@localhost>