The QNX port was previously untested. Now, with the help of a QNX employee,
here are modifications that makes the tests of fbufmode, fflush, fpending,
freadahead, freading, fseterr, ftell, ftello, fwriting all pass.
The fpurge test may or may not pass, I don't know.
The fseek, fseeko tests fail,
Here's the unfinished and untested port to QNX of the stdio extension
modules. Since it's likely to be a better starting point for whomever
volunteers to support that platform than no port at all, I'm committing it.
2007-10-03 Bruno Haible <[EMAIL PROTECTED]>
Port the stdio extensions
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, BeO
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.
> Consider a system where FILE * is opaque which is possible wh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Sean Boudreau on 10/3/2007 6:49 AM:
> Sorry, I thought we were still in the m4 realm.
Yes, it would be nice if m4 didn't have problems with the gnulib portion
of the testsuite on compliant platforms, for the part of gnulib that got
sucked
On Tue, Oct 02, 2007 at 09:19:32PM -0400, Bruno Haible wrote:
> Hello Sean,
>
> Sean Boudreau wrote:
> > Under QNX with 1.4.10 the only things that actually need
> > fpurge() and freading() are their tests. The tests fail but
> > in this context it doesn't matter. Or are you saying their
> > rol
Hello Sean,
Sean Boudreau wrote:
> Under QNX with 1.4.10 the only things that actually need
> fpurge() and freading() are their tests. The tests fail but
> in this context it doesn't matter. Or are you saying their
> role has expanded post 1.4.10?
The role of gnulib is to provide generally usef
On Mon, Oct 01, 2007 at 05:54:52PM -0400, Bruno Haible wrote:
> Sean Boudreau wrote:
> > They're non standard and present challenges in the portability
> department
> > so if they aren't needed the less they're referenced the better.
>
> I agree with you. We considered this point. (For example, th
Sean Boudreau wrote:
> They're non standard and present challenges in the portability department
> so if they aren't needed the less they're referenced the better.
I agree with you. We considered this point. (For example, there is a way
to implement the 'close-stream' module with fpending and one
On Sun, Sep 30, 2007 at 06:51:04PM -0400, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Sean Boudreau on 9/30/2007 4:10 PM:
> > Hello:
>
> Hello Sean, and adding bug-gnulib,
>
> >
> > Would it be possible to not bring in freading.c and fpurge.c
> > and to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Sean Boudreau on 9/30/2007 4:10 PM:
> Hello:
Hello Sean, and adding bug-gnulib,
>
> Would it be possible to not bring in freading.c and fpurge.c
> and to disable the associated tests if fflush() behaves as
> you expect?
For m4 1.4.x: I
--- Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hello,
>
> > allocating pseudo-terminals in a portable way is a
> nightmare.
>
> I agree. You also find some source code in this
> direction in glibc,
I found the relevant source in glibc much more
readable than my previous attempt with expect.
> i
Hello,
> allocating pseudo-terminals in a portable way is a nightmare.
I agree. You also find some source code in this direction in glibc,
in xterm (horrible mess of #ifdefs), in kdebase/konsole, in rxvt,
in gnome-terminal, ...
> It would be nice if gnulib included portable
> replacements for GN
13 matches
Mail list logo
