libio patches for glibc 2.1

libio patches for glibc 2.1

[Andreas Schwab]

This patch fixes some problems in libio in connection with glibc 2.1.
Note that the change of _IO_wchar_t is a binary incompatibility, so users
of glibc 2.1 snapshots need to recompile at least all code that uses
[io]fstream.


1998-02-22  Andreas Schwab  <schwab@issan.informatik.uni-dortmund.de>

	Changes for _G_IO_IO_FILE_VERSION == 0x20001:
	* libioP.h (_IO_showmanyc_t, _IO_SHOWMANYC, _IO_imbue_t,
	_IO_IMBUE): New definitions.
	(struct _IO_jump_t): Add __showmanyc and __imbue fields.
	(_IO_file_fopen): Add new fourth argument.
	* filebuf.cc (filebuf::open): Pass new fourth argument to
	_IO_file_fopen.
	* iolibio.h (_IO_freopen): Likewise.
	* streambuf.cc (streambuf::showmanyc, streambuf::imbue): New
	functions.
	* streambuf.h (_IO_wchar_t): Define to _G_wchar_t.
	(ios::fill): Remove casts.
	(struct streambuf): Add showmanyc and imbue members.

	* iostream.cc (ostream::operator<<(double n)) [__GLIBC_MINOR__ >=
	1]: Initialize new fields is_char of struct printf_info.
	(ostream::operator<<(long double n)) [__GLIBC_MINOR__ >= 1]:
	Likewise.

--- egcs-980214/libio/filebuf.cc.~1~	Fri Feb  6 23:01:41 1998
+++ egcs-980214/libio/filebuf.cc	Mon Jan 12 23:03:35 1998
@@ -131,7 +131,11 @@
 
 filebuf* filebuf::open(const char *filename, const char *mode)
 {
+#if _G_IO_IO_FILE_VERSION == 0x20001
+  return (filebuf*)_IO_file_fopen(this, filename, mode, 0);
+#else
   return (filebuf*)_IO_file_fopen(this, filename, mode);
+#endif
 }
 
 filebuf* filebuf::attach(int fd)
--- egcs-980214/libio/iolibio.h.~1~	Tue Sep 16 18:00:11 1997
+++ egcs-980214/libio/iolibio.h	Fri Jan 16 20:31:20 1998
@@ -45,8 +45,13 @@
   (_IO_seekoff(__fp, __offset, __whence, _IOS_INPUT|_IOS_OUTPUT) == _IO_pos_BAD ? EOF : 0)
 #define _IO_rewind(FILE) (void)_IO_seekoff(FILE, 0, 0, _IOS_INPUT|_IOS_OUTPUT)
 #define _IO_vprintf(FORMAT, ARGS) _IO_vfprintf(_IO_stdout, FORMAT, ARGS)
+#if _G_IO_IO_FILE_VERSION == 0x20001
+#define _IO_freopen(FILENAME, MODE, FP) \
+  (_IO_file_close_it(FP), _IO_file_fopen(FP, FILENAME, MODE, 0))
+#else
 #define _IO_freopen(FILENAME, MODE, FP) \
   (_IO_file_close_it(FP), _IO_file_fopen(FP, FILENAME, MODE))
+#endif
 #define _IO_fileno(FP) ((FP)->_fileno)
 extern _IO_FILE* _IO_popen __P((const char*, const char*));
 #define _IO_pclose _IO_fclose
--- egcs-980214/libio/iostream.cc.~1~	Mon Feb 16 19:52:43 1998
+++ egcs-980214/libio/iostream.cc	Sun Feb 22 16:03:55 1998
@@ -634,6 +634,9 @@
 				      /* group: */ 0,
 #if defined __GLIBC__ && __GLIBC__ >= 2
 				      /* extra: */ 0,
+#if __GLIBC_MINOR__ >= 1
+				      /* is_char: */ 0,
+#endif
 #endif
 				      /* pad: */ fill()
 	  };
@@ -737,6 +740,9 @@
 				  /* group: */ 0,
 #if defined __GLIBC__ && __GLIBC__ >= 2
 				  /* extra: */ 0,
+#if __GLIBC_MINOR__ >= 1
+				  /* is_char: */ 0,
+#endif
 #endif
 				  /* pad: */ fill()
       };
--- egcs-980214/libio/libioP.h.~1~	Fri Feb  6 23:01:46 1998
+++ egcs-980214/libio/libioP.h	Sun Feb 22 16:13:13 1998
@@ -226,6 +226,19 @@
 typedef int (*_IO_stat_t) __P ((_IO_FILE *, void *));
 #define _IO_SYSSTAT(FP, BUF) JUMP1 (__stat, FP, BUF)
 
+#if _G_IO_IO_FILE_VERSION == 0x20001
+/* The 'showmany' hook can be used to get an image how much input is
+   available.  In many cases the answer will be 0 which means unknown
+   but some cases one can provide real information.  */
+typedef int (*_IO_showmanyc_t) __P ((_IO_FILE *));
+#define _IO_SHOWMANYC(FP) JUMP0 (__showmanyc, FP)
+
+/* The 'imbue' hook is used to get information about the currently
+   installed locales.  */
+typedef void (*_IO_imbue_t) __P ((_IO_FILE *, void *));
+#define _IO_IMBUE(FP, LOCALE) JUMP1 (__imbue, FP, LOCALE)
+#endif
+
 
 #define _IO_CHAR_TYPE char /* unsigned char ? */
 #define _IO_INT_TYPE int
@@ -254,6 +267,10 @@
     JUMP_FIELD(_IO_seek_t, __seek);
     JUMP_FIELD(_IO_close_t, __close);
     JUMP_FIELD(_IO_stat_t, __stat);
+#if _G_IO_IO_FILE_VERSION == 0x20001
+    JUMP_FIELD(_IO_showmanyc_t, __showmanyc);
+    JUMP_FIELD(_IO_imbue_t, __imbue);
+#endif
 #if 0
     get_column;
     set_column;
@@ -381,7 +398,12 @@
 extern _IO_FILE* _IO_file_attach __P ((_IO_FILE *, int));
 extern _IO_FILE* _IO_file_open __P ((_IO_FILE *, const char *, int, int,
 				     int, int));
+#if _G_IO_IO_FILE_VERSION == 0x20001
+extern _IO_FILE* _IO_file_fopen __P ((_IO_FILE *, const char *, const char *,
+				      int));
+#else
 extern _IO_FILE* _IO_file_fopen __P ((_IO_FILE *, const char *, const char *));
+#endif
 extern _IO_ssize_t _IO_file_write __P ((_IO_FILE *, const void *,
 					_IO_ssize_t));
 extern _IO_ssize_t _IO_file_read __P ((_IO_FILE *, void *, _IO_ssize_t));
--- egcs-980214/libio/streambuf.cc.~1~	Sat Dec  6 08:32:08 1997
+++ egcs-980214/libio/streambuf.cc	Fri Jan 16 20:28:29 1998
@@ -301,6 +301,17 @@
 
 int streambuf::sys_close() { return 0; /* Suceess; do nothing */ }
 
+#if _G_IO_IO_FILE_VERSION == 0x20001
+int streambuf::showmanyc()
+{
+  return -1;
+}
+
+void streambuf::imbue(void *)
+{
+}
+#endif
+
 streammarker::streammarker(streambuf *sb)
 {
   _IO_init_marker(this, sb);
--- egcs-980214/libio/streambuf.h.~1~	Fri Feb  6 23:01:47 1998
+++ egcs-980214/libio/streambuf.h	Mon Feb 16 21:46:50 1998
@@ -55,8 +55,12 @@
 #endif
 
 #ifndef _IO_wchar_t
+#if _G_IO_IO_FILE_VERSION == 0x20001
+#define _IO_wchar_t _G_wchar_t
+#else
 #define _IO_wchar_t short
 #endif
+#endif
 
 extern "C++" {
 class istream; /* Work-around for a g++ name mangling bug. Fixed in 2.6. */
@@ -176,9 +180,9 @@
     ostream* tie(ostream* val) { ostream* save=_tie; _tie=val; return save; }
 
     // Methods to change the format state.
-    _IO_wchar_t fill() const { return (_IO_wchar_t)_fill; }
+    _IO_wchar_t fill() const { return _fill; }
     _IO_wchar_t fill(_IO_wchar_t newf)
-	{_IO_wchar_t oldf = (_IO_wchar_t)_fill; _fill = (char)newf; return oldf;}
+	{_IO_wchar_t oldf = _fill; _fill = newf; return oldf;}
     fmtflags flags() const { return _flags; }
     fmtflags flags(fmtflags new_val) {
 	fmtflags old_val = _flags; _flags = new_val; return old_val; }
@@ -409,6 +413,10 @@
     virtual streampos sys_seek(streamoff, _seek_dir);
     virtual int sys_close();
     virtual int sys_stat(void*); // Actually, a (struct stat*)
+#if _G_IO_IO_FILE_VERSION == 0x20001
+    virtual int showmanyc();
+    virtual void imbue(void *);
+#endif
 };
 
 // A backupbuf is a streambuf with full backup and savepoints on reading.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"
schwab@gnu.org

Re: libio patches for glibc 2.1

[H.J. Lu]

> 
> This patch fixes some problems in libio in connection with glibc 2.1.
> Note that the change of _IO_wchar_t is a binary incompatibility, so users
> of glibc 2.1 snapshots need to recompile at least all code that uses
> [io]fstream.
> 
> 
> 1998-02-22  Andreas Schwab  <schwab@issan.informatik.uni-dortmund.de>
> 
> 	Changes for _G_IO_IO_FILE_VERSION == 0x20001:
> 	* libioP.h (_IO_showmanyc_t, _IO_SHOWMANYC, _IO_imbue_t,
> 	_IO_IMBUE): New definitions.
> 	(struct _IO_jump_t): Add __showmanyc and __imbue fields.
> 	(_IO_file_fopen): Add new fourth argument.
> 	* filebuf.cc (filebuf::open): Pass new fourth argument to
> 	_IO_file_fopen.
> 	* iolibio.h (_IO_freopen): Likewise.
> 	* streambuf.cc (streambuf::showmanyc, streambuf::imbue): New
> 	functions.
> 	* streambuf.h (_IO_wchar_t): Define to _G_wchar_t.
> 	(ios::fill): Remove casts.
> 	(struct streambuf): Add showmanyc and imbue members.
> 
> 	* iostream.cc (ostream::operator<<(double n)) [__GLIBC_MINOR__ >=
> 	1]: Initialize new fields is_char of struct printf_info.
> 	(ostream::operator<<(long double n)) [__GLIBC_MINOR__ >= 1]:
> 	Likewise.

Ulrich, should this also go into egcs 1.0.2?

H.J.

Re: libio patches for glibc 2.1

[Ulrich Drepper]

hjl@lucon.org (H.J. Lu) writes:

> > 
> > This patch fixes some problems in libio in connection with glibc 2.1.
> > Note that the change of _IO_wchar_t is a binary incompatibility, so users
> > of glibc 2.1 snapshots need to recompile at least all code that uses
> > [io]fstream.
> > [...]
> Ulrich, should this also go into egcs 1.0.2?

I think we should leave it out especially since Jeff plans to have
egcs 1.1 in the not too far future and people who really use glibc 2.1
these days can also use the egcs snapshots (instead of the final 1.0
release).

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: libio patches for glibc 2.1

[H.J. Lu]

> 
> hjl@lucon.org (H.J. Lu) writes:
> 
> > > 
> > > This patch fixes some problems in libio in connection with glibc 2.1.
> > > Note that the change of _IO_wchar_t is a binary incompatibility, so users
> > > of glibc 2.1 snapshots need to recompile at least all code that uses
> > > [io]fstream.
> > > [...]
> > Ulrich, should this also go into egcs 1.0.2?
> 
> I think we should leave it out especially since Jeff plans to have
> egcs 1.1 in the not too far future and people who really use glibc 2.1
> these days can also use the egcs snapshots (instead of the final 1.0
> release).
> 

RedHat, Debian and SuSE may want to use egcs 1.0.x for glibc 2.1 even
if egcs 1.1 is released.

BTW, the current egcs snapshots change a lot. I am using egcs 1.0.x
for glibc 2.1. I don't want to guess which one is at fault, egcs
or glibc, when something goes wrong.

-- 
H.J. Lu (hjl@gnu.org)

Re: libio patches for glibc 2.1

[Ulrich Drepper]

hjl@lucon.org (H.J. Lu) writes:

> RedHat, Debian and SuSE may want to use egcs 1.0.x for glibc 2.1 even
> if egcs 1.1 is released.

I don't see that any of the distributions start using glibc 2.1
sometime soon. It's the same as for egcs 1.1, they wait a bit (this is
first hand information).  Once the distribution makers consider glibc
2.1 we'll also have a stable egcs 1.1.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: libio patches for glibc 2.1

[H.J. Lu]

> 
> hjl@lucon.org (H.J. Lu) writes:
> 
> > RedHat, Debian and SuSE may want to use egcs 1.0.x for glibc 2.1 even
> > if egcs 1.1 is released.
> 
> I don't see that any of the distributions start using glibc 2.1
> sometime soon. It's the same as for egcs 1.1, they wait a bit (this is
> first hand information).  Once the distribution makers consider glibc
> 2.1 we'll also have a stable egcs 1.1.
> 

I, as a glibc 2.1 developer, don't want to use egcs snapshot, which
is known (intentional) to break from time to time, for glibc 2.1. I
want a stable compiler which is compatible with glibc 2.1. I don't 
want another factor in my glibc 2.1 work. Other glibc 2.1
developers/testers may share the similar view with me.


-- 
H.J. Lu (hjl@gnu.org)

Re: libio patches for glibc 2.1

[Ulrich Drepper]

hjl@lucon.org (H.J. Lu) writes:

> I, as a glibc 2.1 developer, don't want to use egcs snapshot, which
> is known (intentional) to break from time to time, for glibc 2.1. I
> want a stable compiler which is compatible with glibc 2.1. I don't 
> want another factor in my glibc 2.1 work.

I do understand this, of course.  The problem is only that by putting
in more and more changes into egcs 1.0 it might not stabilize and
especially with volatile code like the egcs/glibc 2.1 interface this
might require even more changes once egcs 1.0.2 is out.  You should
case about Jeff who really likes to devote his time on egcs 1.1
instead of another 1.0 release.

If Jeff has no objections about adding the code to egcs 1.0, go ahead.
The code itself is correct, my only fear is that it might not be the
last required change.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: libio patches for glibc 2.1

[H.J. Lu]

> 
> hjl@lucon.org (H.J. Lu) writes:
> 
> > I, as a glibc 2.1 developer, don't want to use egcs snapshot, which
> > is known (intentional) to break from time to time, for glibc 2.1. I
> > want a stable compiler which is compatible with glibc 2.1. I don't 
> > want another factor in my glibc 2.1 work.
> 
> I do understand this, of course.  The problem is only that by putting
> in more and more changes into egcs 1.0 it might not stabilize and
> especially with volatile code like the egcs/glibc 2.1 interface this
> might require even more changes once egcs 1.0.2 is out.  You should
> case about Jeff who really likes to devote his time on egcs 1.1
> instead of another 1.0 release.
> 

The changes for glibc 2.1 to egcs will be pretty much limited to
libstdc++/libio. They should not change the gcc directory itself
and they probably won't affect any other systems. They should be
quite safe.


> If Jeff has no objections about adding the code to egcs 1.0, go ahead.
> The code itself is correct, my only fear is that it might not be the
> last required change.
> 

I'd like to see a stable compiler for glibc 2.1.

-- 
H.J. Lu (hjl@gnu.org)

Re: libio patches for glibc 2.1

[Joe Buck]

> I do understand this, of course.  The problem is only that by putting
> in more and more changes into egcs 1.0 it might not stabilize and
> especially with volatile code like the egcs/glibc 2.1 interface this
> might require even more changes once egcs 1.0.2 is out.  You should
> case about Jeff who really likes to devote his time on egcs 1.1
> instead of another 1.0 release.

How can the egcs/glibc interface be made less volatile?  What factors
are causing the problems?

(Clearly these can't all be fixed for egcs 1.0.x, but it would be nice
if egcs and glibc weren't always breaking each other).

Re: libio patches for glibc 2.1

[Ulrich Drepper]

Joe Buck <jbuck@Synopsys.COM> writes:

> How can the egcs/glibc interface be made less volatile?  What factors
> are causing the problems?

The changes in the patch Andreas sent are necessary since libio must
support the extended iostream functionality of the C++ standard.  I've
added the code to glibc already since this is my development
environment.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: libio patches for glibc 2.1

[Joe Buck]

> > How can the egcs/glibc interface be made less volatile?  What factors
> > are causing the problems?
> 
> The changes in the patch Andreas sent are necessary since libio must
> support the extended iostream functionality of the C++ standard.  I've
> added the code to glibc already since this is my development
> environment.

Ah, so the disruption is just for extended and wide streams?  Then it
seems that it should be a one-time thing.

Re: libio patches for glibc 2.1

[Ulrich Drepper]

Joe Buck <jbuck@Synopsys.COM> writes:

> Ah, so the disruption is just for extended and wide streams?  Then it
> seems that it should be a one-time thing.

Not if I missed something.  Wide streams are still not supported since
I've yet to decide how to implement this correctly.  But I've added
some unused padding bytes at the end of the struct so that we can add
new members later.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: libio patches for glibc 2.1

[Joe Buck]

> > Ah, so the disruption is just for extended and wide streams?  Then it
> > seems that it should be a one-time thing.
> 
> Not if I missed something.  Wide streams are still not supported since
> I've yet to decide how to implement this correctly.  But I've added
> some unused padding bytes at the end of the struct so that we can add
> new members later.

Since on the C++ side the wide streams are a different template expansion,
it seems that you are free to use a completely new struct for the libio/C
side of wide streams.  

Re: libio patches for glibc 2.1

[Ulrich Drepper]

Joe Buck <jbuck@Synopsys.COM> writes:

> Since on the C++ side the wide streams are a different template expansion,
> it seems that you are free to use a completely new struct for the libio/C
> side of wide streams.  

Not if I take the whole picture.  In ISO C (which we implement in
glibc using libio) a stream can be used as a normal stream and a wide
char stream if the switching using fwide() is used correctly.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: libio patches for glibc 2.1

[Jeffrey A Law]

  In message < r2en0umazz.fsf@happy.cygnus.com >you write:
  > in more and more changes into egcs 1.0 it might not stabilize and
  > especially with volatile code like the egcs/glibc 2.1 interface this
  > might require even more changes once egcs 1.0.2 is out.  You should
  > case about Jeff who really likes to devote his time on egcs 1.1
  > instead of another 1.0 release.
Exactly!

The longer we continue to work on egcs-1.0.x the longer it will be
before we can deal with egcs-1.1.

Quite a bit of my time to work on egcs is already spent on egcs-1.0.x,
and as a result work on the mainline has slowed.  We need to wrap up
egcs-1.0.x then focus 100% of our effort on egcs-1.1.

jeff

Re: libio patches for glibc 2.1

[Jeffrey A Law]

  In message < m0y71JM-00058gC@ocean.lucon.org >you write:
  > > 
  > > This patch fixes some problems in libio in connection with glibc 2.1.
  > > Note that the change of _IO_wchar_t is a binary incompatibility, so users
  > > of glibc 2.1 snapshots need to recompile at least all code that uses
  > > [io]fstream.
  > > 
  > > 
  > > 1998-02-22  Andreas Schwab  <schwab@issan.informatik.uni-dortmund.de>
  > > 
  > > 	Changes for _G_IO_IO_FILE_VERSION == 0x20001:
  > > 	* libioP.h (_IO_showmanyc_t, _IO_SHOWMANYC, _IO_imbue_t,
  > > 	_IO_IMBUE): New definitions.
  > > 	(struct _IO_jump_t): Add __showmanyc and __imbue fields.
  > > 	(_IO_file_fopen): Add new fourth argument.
  > > 	* filebuf.cc (filebuf::open): Pass new fourth argument to
  > > 	_IO_file_fopen.
  > > 	* iolibio.h (_IO_freopen): Likewise.
  > > 	* streambuf.cc (streambuf::showmanyc, streambuf::imbue): New
  > > 	functions.
  > > 	* streambuf.h (_IO_wchar_t): Define to _G_wchar_t.
  > > 	(ios::fill): Remove casts.
  > > 	(struct streambuf): Add showmanyc and imbue members.
  > > 
  > > 	* iostream.cc (ostream::operator<<(double n)) [__GLIBC_MINOR__ >=
  > > 	1]: Initialize new fields is_char of struct printf_info.
  > > 	(ostream::operator<<(long double n)) [__GLIBC_MINOR__ >= 1]:
  > > 	Likewise.
  > 
  > Ulrich, should this also go into egcs 1.0.2?
I installed this on the release branch too.

At this point I'd like to change modes -- we've installed far more
patches than I would have liked for this release.  I'd like to get
patches for two more problems, then call the release sources frozen
except for end-of-the-world bugs and the usual doc updates so that
we can get the release tested!

We need patches for:

    * -Di386 lossage.  I think we decided to go ahead and define
    i386, except with -ansi is in effect.  Can someone provide a
    patch for this?

    * A fix for the sigset_t problem.  I've got no opinion on what
    the best fix is -- I'm depending on y'all to make that technical
    decision.    



I'm offline March 11 - March 15.  Having the release ready to go by
March 11 would be best.  I might be able to swing March 15 or 16,
but if we go beyond those dates we'll have to push the release into
April due to EOQ concerns at Cygnus.

Re: libio patches for glibc 2.1

[H.J. Lu]

> We need patches for:
> 
>     * -Di386 lossage.  I think we decided to go ahead and define
>     i386, except with -ansi is in effect.  Can someone provide a
>     patch for this?

I think we can provide an cpp script for linux.

> 
>     * A fix for the sigset_t problem.  I've got no opinion on what
>     the best fix is -- I'm depending on y'all to make that technical
>     decision.    
> 

I have proposed an include/g++/signal.h. If it is good enough, I
can implement the rest patch.

-- 
H.J. Lu (hjl@gnu.org)

Re: libio patches for glibc 2.1

[Jason Merrill]

>>>>> Jeffrey A Law <law@cygnus.com> writes:

> We need patches for:

>     * A fix for the sigset_t problem.  I've got no opinion on what
>     the best fix is -- I'm depending on y'all to make that technical
>     decision.    

Fixed.

Jason

Re: libio patches for glibc 2.1

[H.J. Lu]

> 
> >>>>> Jeffrey A Law <law@cygnus.com> writes:
> 
> > We need patches for:
> 
> >     * A fix for the sigset_t problem.  I've got no opinion on what
> >     the best fix is -- I'm depending on y'all to make that technical
> >     decision.    
> 
> Fixed.
> 

I think that fix breaks glibc 2.1 and glibc 2.0.7.

-- 
H.J. Lu (hjl@gnu.org)

Re: libio patches for glibc 2.1

[Jason Merrill]

>>>>> H J Lu <hjl@lucon.org> writes:

>> >>>>> Jeffrey A Law <law@cygnus.com> writes:
>> 
>> > We need patches for:
>> 
>> >     * A fix for the sigset_t problem.  I've got no opinion on what
>> >     the best fix is -- I'm depending on y'all to make that technical
>> >     decision.    
>> 
>> Fixed.
>> 

> I think that fix breaks glibc 2.1 and glibc 2.0.7.

Why?  How?  Please be more specific.

Jason

Re: libio patches for glibc 2.1

[H.J. Lu]

> 
> >>>>> H J Lu <hjl@lucon.org> writes:
> 
> >> >>>>> Jeffrey A Law <law@cygnus.com> writes:
> >> 
> >> > We need patches for:
> >> 
> >> >     * A fix for the sigset_t problem.  I've got no opinion on what
> >> >     the best fix is -- I'm depending on y'all to make that technical
> >> >     decision.    
> >> 
> >> Fixed.
> >> 
> 
> > I think that fix breaks glibc 2.1 and glibc 2.0.7.
> 
> Why?  How?  Please be more specific.
> 

It is ok. I thought the code below was not valid C++. But gcc takes it.
I was wrong. Ulrich, Jason's fix is ok with glibc 2.1 and glibc 2.0.7.
We can close the sigset_t problem now.

Thanks.

-- 
H.J. Lu (hjl@gnu.org)
---
typedef struct
{
  int x [30];
} __sigset_t;

typedef __sigset_t __sigset_t;

Re: libio patches for glibc 2.1

[Robert Wilhelm]

On Wed, Feb 25, 1998 at 07:11:47PM -0800, H.J. Lu wrote:
> 
> I think that fix breaks glibc 2.1 and glibc 2.0.7.
>

IMHO this should not hurt at all, since glibc 2.1 and glibc 2.0.7
are not yet released and could propably be fixed.

Robert

Re: libio patches for glibc 2.1

[H.J. Lu]

> 
> On Wed, Feb 25, 1998 at 07:11:47PM -0800, H.J. Lu wrote:
> > 
> > I think that fix breaks glibc 2.1 and glibc 2.0.7.
> >
> 
> IMHO this should not hurt at all, since glibc 2.1 and glibc 2.0.7
> are not yet released and could propably be fixed.
> 

The problem is that fix to libstdc++ may be wrong and glibc 2.1/2.0.7
are correct. Which one do you fix?

-- 
H.J. Lu (hjl@gnu.org)

Re: libio patches for glibc 2.1

[Jeffrey A Law]

  In message < vyzg1lask1j.fsf@issan.informatik.uni-dortmund.de >you write:
  > This patch fixes some problems in libio in connection with glibc 2.1.
  > Note that the change of _IO_wchar_t is a binary incompatibility, so users
  > of glibc 2.1 snapshots need to recompile at least all code that uses
  > [io]fstream.
  > 
  > 
  > 1998-02-22  Andreas Schwab  <schwab@issan.informatik.uni-dortmund.de>
  > 
  > 	Changes for _G_IO_IO_FILE_VERSION == 0x20001:
  > 	* libioP.h (_IO_showmanyc_t, _IO_SHOWMANYC, _IO_imbue_t,
  > 	_IO_IMBUE): New definitions.
  > 	(struct _IO_jump_t): Add __showmanyc and __imbue fields.
  > 	(_IO_file_fopen): Add new fourth argument.
  > 	* filebuf.cc (filebuf::open): Pass new fourth argument to
  > 	_IO_file_fopen.
  > 	* iolibio.h (_IO_freopen): Likewise.
  > 	* streambuf.cc (streambuf::showmanyc, streambuf::imbue): New
  > 	functions.
  > 	* streambuf.h (_IO_wchar_t): Define to _G_wchar_t.
  > 	(ios::fill): Remove casts.
  > 	(struct streambuf): Add showmanyc and imbue members.
  > 
  > 	* iostream.cc (ostream::operator<<(double n)) [__GLIBC_MINOR__ >=
  > 	1]: Initialize new fields is_char of struct printf_info.
  > 	(ostream::operator<<(long double n)) [__GLIBC_MINOR__ >= 1]:
  > 	Likewise.
Normally I'd ask you to install these patches, but I already had the
patchkit handy from installing it on the release branch.  So I went
ahead and too care of it myself.

Thanks!
jeff

Re: libio patches for glibc 2.1

[Mike Stump]

> From: Joe Buck <jbuck@synopsys.com>
> To: drepper@cygnus.com
> Date: Mon, 23 Feb 98 14:09:29 PST
> Cc: hjl@lucon.org, egcs@cygnus.com

> How can the egcs/glibc interface be made less volatile?  What factors
> are causing the problems?

Oh, this one it too easy.  If GNU libc had only a C interface that was
stabilized on 5 years ago, then it would be stable.

Once you add a changing C++ class into the interface, a changing
interface, changing requirements for C++, things get interesting.