On Wed, Oct 03, 2007 at 10:07:28AM -0400, Bruno Haible wrote: > Sean Boudreau wrote: > > If it were a simple matter of porting I would have done it > > It is a simple matter of porting. The code is already ported to GNU > libc, > *BSD, MacOS X, AIX, HP-UX, IRIX, OSF/1, Solaris, Cygwin, mingw, BeOS, > uClibc.
As I mentioned, there are difficulties where FILE * is opaque which is not counter POSIX. This whole discussion started in m4 land where the gnulib fflush() is being brought in for POSIX conformance where it isn't needed. Our opaque parts are under license which probably interests you less than any part of this discussion thus far; however because of this something like the aforementioned fbufmode.c approach for solaris amd64 probably isn't viable. So it's more than a simple matter of porting. > > > Consider a system where FILE * is opaque which is possible while > maintaining > > POSIX conformance. > > This is a theoretical argumentation. coreutils, emacs, Perl all rely on > internal fields of FILE that are not specified by POSIX. > coreutils for closing streams reliably > emacs PENDING_OUTPUT_COUNT macro > Perl see perlio.c Perl doesn't always fiddle with FILE * and builds fine on QNX. As you say, "not specified by POSIX" which is my point. I find it ironic that in trying to enhance POSIX conformance m4 brings in non POSIX extensions and therefore doesn't build in a POSIX environment. I also said (maybe in m4 land) that I don't consider this a true gnulib issue. gnulib can do what it likes but portable code shouldn't use it (or at least the stdio extensions). Thanks for your time -seanb
