Eric Blake wrote: > According to Brian Dessent on 3/9/2008 6:23 AM: > | Current unreleased Cygwin CVS (which will be 1.7.0 at some point in the > | not too distant future) has support for fopencookie() and funopen(), > | however this causes building autogen to fail. Autogen seems to be > | assuming it's on glibc if these functions are detected. > > I implemented newlib's fopencookie (as used in cygwin) after Linux's, > except that it is declared solely in <stdio.h> rather than <libio.h>. If > the signature and usage doesn't match Linux (other than which header to > use), then that is a bug in newlib that should be corrected, and > preferably before cygwin 1.7.0 is released.
Why not prototype the thing in "libio.h"? What's the advantage of having an ever so slightly different implementation? > Also, I implemented fmemopen directly in newlib, although cygwin hasn't > incorporated it yet (even though it is being standardized by POSIX 200x). fmemopen is a bad interface. It is fine if you only ever read/write fixed length strings. That's not what I'm doing and even in real life (day job programming), I have little need of a fixed string size implementation. > ~ Maybe it would be better to get cygwin to incorporate fmemopen, then > have autogen use fmemopen directly rather than its wrapper using > fopencookie/funopen when the platform has a working fmemopen. fmemopen is not useful. Sorry. :( > | then it detects funopen() and tries to > | use that but also fails because its idea of the cookie function > | signitures differs from Cygwin/newlib's: > > This one is a bit different. funopen comes from BSD heritage, but newlib > had already changed the signature different that what was present in BSD. > ~ Since funopen is not standardized, you will just have to do a > configure-time test for what signature it uses, since changing the > signature now would break any existing newlib app that relies on the > existing funopen signature. I don't think either is standardized. Nevertheless, it seems an odd choice to not follow the prototype that BSD chose. And both mechanisms failed to provide a way to map the returned FILE* pointer to the internal-to-the-mechanism data. e.g. fmemioctl(FILE*, void* data). You're probably not in a position to influence directions -- I'm just grousing. :) So, please send me a config test to be able to differentiate the first-born "funopen" from the one of CygWin heritage. I'll add an "is there a libio.h header?" guard around the #include. Thanks - Bruce ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Autogen-users mailing list Autogen-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/autogen-users
