libc: Add fopencookie(3) wrapper around funopen(3)
ClosedPublic
Actions

Authored by cem on May 9 2016, 9:57 PM.

Details

Reviewers

jilles
pfg
jhb
ache
oshogbo

Group Reviewers

manpages

Commits

rS299456: libc: Add fopencookie(3) wrapper around funopen(3)

Summary

Given how similar funopen(3) and fopencookie(3) are aside from API, it is
unfortunate that programs that use the latter need ifdefs and slight code
changes to be portable between platforms.

So, adopt the glibc interface.

Yes, BSD had funopen(3) first and glibc decided to do their own thing. I don't
think spite is a good reason not to ease portability, though. Adding the shim
is cheap and doesn't hurt. Finally, with both interfaces we are in good shape
regardless which, if any, interface becomes standard.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 3645
Build 3688: arc lint + arc unit

Event Timeline

cem updated this revision to Diff 16091.May 9 2016, 9:57 PM

cem retitled this revision from to libc: Add fopencookie(3) wrapper around funopen(3).

cem updated this object.

cem edited the test plan for this revision. (Show Details)

cem added reviewers: oshogbo, jilles, jhb, pfg, ache.

cem added a subscriber: • rodrigc.

Herald added a reviewer: manpages. · View Herald TranscriptMay 9 2016, 9:57 PM

Herald added a subscriber: imp. · View Herald Transcript

Would be nice to fix the funopen callbacks to work with size_t, etc. That's a bit of a harrier mess though one could do it with a newer "version" of funopen() via symver if the API change was considered ok for 11.0 or 12.0.

This revision is now accepted and ready to land.May 9 2016, 10:11 PM

In D6282#133555, @jhb wrote:

Would be nice to fix the funopen callbacks to work with size_t, etc. That's a bit of a harrier mess though one could do it with a newer "version" of funopen() via symver if the API change was considered ok for 11.0 or 12.0.

Right. The function pointers in sFILE today can only handle the int types. In practice I think 32-bit buffer sizes are probably fine (I don't think it's the performance bottleneck of the read(2)/write(2) interface).

I guess new function pointers or a flag or something could be added to sFILE to distinguish int-funopen-compat sFILEs from size_t-funopen sFILEs? Out of scope for this change, anyway.

Yes, out of scope. I was thinking you would change sFILE to always use size_t and add thunk wrappers for the compat version of funopen() that called the older API callbacks (similar to what you did here)