[Guido]
> I expect that the right solution here is indeed to write our own
> stdio-like library from the ground up. That can solve any number of
> problems: telling how many characters are buffered (so you don't have
> to use unbuffered mode when using select or poll), platform-
> independent line end recognition, and super-efficient readline()
> to boot.
We also have the old
http://sourceforge.net/tracker/?group_id=5470&
atid=105470&func=detail&aid=210821
complaining that use of FILE* in our C API can make it impossible to (in that
fellow's case) write an app in Borland C++ on Windows that tries to use those
API functions (cuz Borland's FILE* is incompatible with MS's FILE*). I'm not
sure the best solution to *that* is to give them a FILE* that's incompatible
with everyone's, though <wink>>
> But it's a lot of work, and won't be compatible with existing
> extensions that use FILE* (not too many I believe).
I'm more concerned about the "lot of work" part, with which I agree.
OTOH, Plauger's book "The Standard C Library" contains source code for every
library required by C89. He reported that implementing libm took him twice
as long as everything else combined. But those who haven't written a libm
will be prone to take a wrong lesson from that <wink>.
it's-not-that-i/o-is-easy-despite-that-his-libm-code-isn't-production-
quality-ly y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4