Re: QNX and stdio extension modules (was: Re: gnulib request)

[Sean Boudreau]

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