Update.glibc-2.1cvs/glibc-2_1

1999-02-04  Ulrich Drepper  <drepper@cygnus.com>

	* stdlib/strtoll.c: Add alias __strtoq_internal.
	* stdlib/strtoull.c: Add alias __strtouq_internal.

	* wcsmbs/mbrtowc.c: Correct logic testing for converted NUL
	character.  Patch by Owen Taylor <otaylor@redhat.com>.

8 files changed, 82 insertions, 71 deletions

diff --git a/ChangeLog b/ChangeLog
index 93ffdf2..2b381ba 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+1999-02-04  Ulrich Drepper  <drepper@cygnus.com>
+
+	* stdlib/strtoll.c: Add alias __strtoq_internal.
+	* stdlib/strtoull.c: Add alias __strtouq_internal.
+
+	* wcsmbs/mbrtowc.c: Correct logic testing for converted NUL
+	character.  Patch by Owen Taylor <otaylor@redhat.com>.
+
 1999-02-03  Mark Kettenis  <kettenis@gnu.org>
 
 	* sysdeps/mach/hurd/utimes.c (__utimes): Deal with TVP being NULL.
diff --git a/FAQ b/FAQ
index 4b941e7..8dfc525 100644
--- a/FAQ
+++ b/FAQ
@@ -203,11 +203,11 @@ a local mirror first.
 
 You should always try to use the latest official release.  Older versions
 may not have all the features GNU libc requires.  The current releases of
-egcs (1.0.3 and 1.1) and GNU CC (2.8.1) should work with the GNU C library
-(for powerpc see question 1.5; for ARM see question 1.6).
+egcs (1.0.3 and 1.1.1) should work with the GNU C library (for powerpc see
+question 1.5; for ARM see question 1.6).
 
-{ZW} You may have problems if you try to mix code compiled with
-EGCS and with GCC 2.8.1. See question 2.8 for details.
+{ZW} Due to problems with C++ exception handling, you must use EGCS (any
+version) to compile version 2.1 of GNU libc.  See question 2.8 for details.
 
 
 1.3.	When I try to compile glibc I get only error messages.
@@ -338,7 +338,7 @@ to the root of the 2.2 tree and do `make include/linux/version.h'.
 static arrays is very slow.  The compiler will eventually finish; give it
 time.
 
-The problem is fixed in egcs 1.1 but not in earlier releases.
+The problem is fixed in egcs 1.1.
 
 
 1.10.	When I run `nm -u libc.so' on the produced library I still
@@ -729,8 +729,7 @@ libc.  It doesn't matter what compiler you use to compile your program.
 
 For glibc 2.1, we've chosen to do it the other way around: libc.so
 explicitly provides the EH functions.  This is to prevent other shared
-libraries from doing it.  You must therefore compile glibc 2.1 with EGCS
-unless you don't care about ever importing binaries from other systems.
+libraries from doing it.  You must therefore compile glibc 2.1 with EGCS.
 Again, it doesn't matter what compiler you use for your programs.
 
 
diff --git a/FAQ.in b/FAQ.in
index 73eb0ad..9a8c799 100644
--- a/FAQ.in
+++ b/FAQ.in
@@ -60,11 +60,11 @@ a local mirror first.
 
 You should always try to use the latest official release.  Older versions
 may not have all the features GNU libc requires.  The current releases of
-egcs (1.0.3 and 1.1) and GNU CC (2.8.1) should work with the GNU C library
-(for powerpc see ?powerpc; for ARM see ?arm).
+egcs (1.0.3 and 1.1.1) should work with the GNU C library (for powerpc see
+?powerpc; for ARM see ?arm).
 
-{ZW} You may have problems if you try to mix code compiled with
-EGCS and with GCC 2.8.1. See ?exception for details.
+{ZW} Due to problems with C++ exception handling, you must use EGCS (any
+version) to compile version 2.1 of GNU libc.  See ?exception for details.
 
 ??	When I try to compile glibc I get only error messages.
 	What's wrong?
@@ -188,7 +188,7 @@ to the root of the 2.2 tree and do `make include/linux/version.h'.
 static arrays is very slow.  The compiler will eventually finish; give it
 time.
 
-The problem is fixed in egcs 1.1 but not in earlier releases.
+The problem is fixed in egcs 1.1.
 
 ??	When I run `nm -u libc.so' on the produced library I still
 	find unresolved symbols.  Can this be ok?
@@ -562,8 +562,7 @@ libc.  It doesn't matter what compiler you use to compile your program.
 
 For glibc 2.1, we've chosen to do it the other way around: libc.so
 explicitly provides the EH functions.  This is to prevent other shared
-libraries from doing it.  You must therefore compile glibc 2.1 with EGCS
-unless you don't care about ever importing binaries from other systems.
+libraries from doing it.  You must therefore compile glibc 2.1 with EGCS.
 Again, it doesn't matter what compiler you use for your programs.
 
 ??	How can I compile gcc 2.7.2.1 from the gcc source code using
diff --git a/INSTALL b/INSTALL
index 720c540..f8ebfa8 100644
--- a/INSTALL
+++ b/INSTALL
@@ -249,12 +249,13 @@ build the GNU C library:
    * EGCS 1.1.1, 1.1 or 1.0.3
 
      The GNU C library can only be compiled with the GNU C compiler
-     family.  We recommend EGCS 1.0.3 or higher.  GCC 2.8.1 and older
-     versions of EGCS may have problems, particularly on non-Intel
-     architectures.  GCC 2.7.x has catastrophic bugs and cannot be used
-     at all.  (You can use GCC 2.7.x to compile programs that use GNU
-     libc, but you may have problems, particularly with the math
-     functions.)
+     family.  As of the 2.1 release, EGCS 1.0.3 or higher is required.
+     GCC 2.8.1 cannot be used due to an incompatible implementation of
+     some internal compiler support routines; see the FAQ for details.
+     GCC 2.7.x is simply too buggy.  You can use whatever compiler you
+     like to compile programs that use GNU libc, but be aware that both
+     GCC 2.7 and 2.8 have bugs in their floating-point support that may
+     be triggered by the math library.
 
      On Alpha machines you need at least EGCS 1.1.1.  Earlier versions
      don't work reliably.
@@ -262,7 +263,7 @@ build the GNU C library:
      For PPC you might need some patches even on top of the last EGCS
      version.  See the FAQ.
 
-   * GNU `binutils' 2.9.1, or 2.9.1.0.16
+   * GNU `binutils' 2.9.1, 2.9.1.0.16, or later 2.9.1.0.x release
 
      You must use GNU binutils (as and ld) if you want to build a shared
      library.  Even if you don't, we recommend you use them anyway.  No
@@ -270,9 +271,10 @@ build the GNU C library:
 
      The quality of binutils releases has varied a bit recently.  The
      bugs are in obscure features, but glibc uses quite a few of those.
-     2.9.1 and 2.9.1.0.16 are known to work.  Versions after 2.8.1.0.23
-     may or may not work.  Older versions definitely don't.  2.9.1.0.16
-     is required on some platforms, like PPC and Arm.
+     2.9.1, 2.9.1.0.16, and later 2.9.1.0.x releases are known to
+     work.  Versions after 2.8.1.0.23 may or may not work.  Older
+     versions definitely don't.  2.9.1.0.16 or higher is required on
+     some platforms, like PPC and Arm.
 
      For PPC you might need some patches even on top of the last
      binutils version.  See the FAQ.
@@ -298,7 +300,7 @@ build the GNU C library:
 
 If you change any of the `configure.in' files you will also need
 
-   * GNU `autoconf' 2.12
+   * GNU `autoconf' 2.12 or higher
 
 and if you change any of the message translation files you will need
 
@@ -367,19 +369,19 @@ Specific advice for Linux systems
 =================================
 
    If you are installing GNU libc on a Linux system, you need to have
-the header files from a development kernel around for reference.  You
-do not need to use the development kernel, just have its headers where
-glibc can get at them.  The easiest way to do this is to unpack a
-development kernel in a directory such as `/usr/src/linux-dev'.  In that
-directory, run `make config' and accept all the defaults.  Then
-configure glibc with the option
-`--with-headers=/usr/src/linux-dev/include'.  Use the latest
-development kernel you can get your hands on.
-
-   An alternate tactic is to unpack the development kernel and run
-`make config' as above.  Then rename or delete `/usr/include', create a
-new `/usr/include', and make the usual symbolic links of
-`/usr/include/linux' and `/usr/include/asm' into the development kernel
+the header files from a 2.2 kernel around for reference.  You do not
+need to use the 2.2 kernel, just have its headers where glibc can get
+at them.  The easiest way to do this is to unpack it in a directory
+such as `/usr/src/linux-2.2.1'.  In that directory, run `make config'
+and accept all the defaults.  Then run `make include/linux/version.h'.
+Finally, configure glibc with the option
+`--with-headers=/usr/src/linux-2.2.1/include'.  Use the most recent
+kernel you can get your hands on.
+
+   An alternate tactic is to unpack the 2.2 kernel and run `make
+config' as above.  Then rename or delete `/usr/include', create a new
+`/usr/include', and make the usual symbolic links of
+`/usr/include/linux' and `/usr/include/asm' into the 2.2 kernel
 sources.  You can then configure glibc with no special options.  This
 tactic is recommended if you are upgrading from libc5, since you need
 to get rid of the old header files anyway.
diff --git a/manual/install.texi b/manual/install.texi
index a05114d..bfd1ca6 100644
--- a/manual/install.texi
+++ b/manual/install.texi
@@ -279,11 +279,12 @@ Version 3.76.1 seems OK but some people have reported problems.
 EGCS 1.1.1, 1.1 or 1.0.3
 
 The GNU C library can only be compiled with the GNU C compiler family.
-We recommend EGCS 1.0.3 or higher.  GCC 2.8.1 and older versions of EGCS
-may have problems, particularly on non-Intel architectures.  GCC 2.7.x
-has catastrophic bugs and cannot be used at all.  (You can use GCC 2.7.x
-to compile programs that use GNU libc, but you may have problems,
-particularly with the math functions.)
+As of the 2.1 release, EGCS 1.0.3 or higher is required.  GCC 2.8.1 cannot
+be used due to an incompatible implementation of some internal compiler
+support routines; see the FAQ for details.  GCC 2.7.x is simply too
+buggy.  You can use whatever compiler you like to compile programs that
+use GNU libc, but be aware that both GCC 2.7 and 2.8 have bugs in their
+floating-point support that may be triggered by the math library.
 
 On Alpha machines you need at least EGCS 1.1.1.  Earlier versions don't
 work reliably.
@@ -292,17 +293,17 @@ For PPC you might need some patches even on top of the last EGCS version.
 See the FAQ.
 
 @item
-GNU @code{binutils} 2.9.1, or 2.9.1.0.16
+GNU @code{binutils} 2.9.1, 2.9.1.0.16, or later 2.9.1.0.x release
 
 You must use GNU binutils (as and ld) if you want to build a shared
 library.  Even if you don't, we recommend you use them anyway.  No one
 has tested compilation with non-GNU binutils in a long time.
 
 The quality of binutils releases has varied a bit recently.  The bugs
-are in obscure features, but glibc uses quite a few of those.
-2.9.1 and 2.9.1.0.16 are known to work.  Versions after
-2.8.1.0.23 may or may not work.  Older versions definitely don't.
-2.9.1.0.16 is required on some platforms, like PPC and Arm.
+are in obscure features, but glibc uses quite a few of those.  2.9.1,
+2.9.1.0.16, and later 2.9.1.0.x releases are known to work.  Versions
+after 2.8.1.0.23 may or may not work.  Older versions definitely don't.
+2.9.1.0.16 or higher is required on some platforms, like PPC and Arm.
 
 For PPC you might need some patches even on top of the last binutils
 version.  See the FAQ.
@@ -335,7 +336,7 @@ If you change any of the @file{configure.in} files you will also need
 
 @itemize @bullet
 @item
-GNU @code{autoconf} 2.12
+GNU @code{autoconf} 2.12 or higher
 @end itemize
 
 @noindent
@@ -417,23 +418,23 @@ switches via @var{CFLAGS}.
 @cindex upgrading from libc5
 @cindex kernel header files
 
-If you are installing GNU libc on a Linux system, you need to have the
-header files from a development kernel around for reference.  You do not
-need to use the development kernel, just have its headers where glibc
-can get at them.  The easiest way to do this is to unpack a development
-kernel in a directory such as @file{/usr/src/linux-dev}.  In that
-directory, run @samp{make config} and accept all the defaults.  Then
-configure glibc with the option
-@samp{--with-headers=/usr/src/linux-dev/include}.  Use the latest
-development kernel you can get your hands on.
-
-An alternate tactic is to unpack the development kernel and run
-@samp{make config} as above.  Then rename or delete @file{/usr/include},
-create a new @file{/usr/include}, and make the usual symbolic links of
-@file{/usr/include/linux} and @file{/usr/include/asm} into the
-development kernel sources.  You can then configure glibc with no
-special options.  This tactic is recommended if you are upgrading from
-libc5, since you need to get rid of the old header files anyway.
+If you are installing GNU libc on a Linux system, you need to have
+the header files from a 2.2 kernel around for reference.  You do not
+need to use the 2.2 kernel, just have its headers where glibc can get
+at them.  The easiest way to do this is to unpack it in a directory
+such as @file{/usr/src/linux-2.2.1}.  In that directory, run
+@samp{make config} and accept all the defaults.  Then run @samp{make
+include/linux/version.h}.  Finally, configure glibc with the option
+@samp{--with-headers=/usr/src/linux-2.2.1/include}.  Use the most recent
+kernel you can get your hands on.
+
+An alternate tactic is to unpack the 2.2 kernel and run @samp{make
+config} as above.  Then rename or delete @file{/usr/include}, create
+a new @file{/usr/include}, and make the usual symbolic links of
+@file{/usr/include/linux} and @file{/usr/include/asm} into the 2.2
+kernel sources.  You can then configure glibc with no special options.
+This tactic is recommended if you are upgrading from libc5, since you
+need to get rid of the old header files anyway.
 
 Note that @file{/usr/include/net} and @file{/usr/include/scsi} should
 @strong{not} be symlinks into the kernel sources.  GNU libc provides its
diff --git a/stdlib/strtoll.c b/stdlib/strtoll.c
index e9487ad..cfa98c8 100644
--- a/stdlib/strtoll.c
+++ b/stdlib/strtoll.c
@@ -1,5 +1,5 @@
 /* Function to parse a `long long int' from text.
-   Copyright (C) 1995, 1996, 1997 Free Software Foundation, Inc.
+   Copyright (C) 1995, 1996, 1997, 1999 Free Software Foundation, Inc.
    This file is part of the GNU C Library.
 
    The GNU C Library is free software; you can redistribute it and/or
@@ -21,4 +21,5 @@
 
 #include <strtol.c>
 
+strong_alias (__strtoll_internal, __strtoq_internal)
 weak_alias (strtoll, strtoq)
diff --git a/stdlib/strtoull.c b/stdlib/strtoull.c
index 419d289..ef80829 100644
--- a/stdlib/strtoull.c
+++ b/stdlib/strtoull.c
@@ -1,5 +1,5 @@
 /* Function to parse an `unsigned long long int' from text.
-   Copyright (C) 1995, 1996, 1997 Free Software Foundation, Inc.
+   Copyright (C) 1995, 1996, 1997, 1999 Free Software Foundation, Inc.
    This file is part of the GNU C Library.
 
    The GNU C Library is free software; you can redistribute it and/or
@@ -21,4 +21,5 @@
 
 #include <strtoul.c>
 
+strong_alias (__strtoull_internal, __strtouq_internal)
 weak_alias (strtoull, strtouq)
diff --git a/wcsmbs/mbrtowc.c b/wcsmbs/mbrtowc.c
index 837b42f..bf995ec 100644
--- a/wcsmbs/mbrtowc.c
+++ b/wcsmbs/mbrtowc.c
@@ -1,6 +1,6 @@
-/* Copyright (C) 1996, 1997, 1998 Free Software Foundation, Inc.
+/* Copyright (C) 1996, 1997, 1998, 1999 Free Software Foundation, Inc.
    This file is part of the GNU C Library.
-   Contributed by Ulrich Drepper <drepper@gnu.ai.mit.edu>, 1996.
+   Contributed by Ulrich Drepper <drepper@gnu.org>, 1996.
 
    The GNU C Library is free software; you can redistribute it and/or
    modify it under the terms of the GNU Library General Public License as
@@ -80,7 +80,7 @@ __mbrtowc (wchar_t *pwc, const char *s, size_t n, mbstate_t *ps)
   if (status == GCONV_OK || status == GCONV_EMPTY_INPUT
       || status == GCONV_FULL_OUTPUT)
     {
-      if (data.outbuf != outbuf && *(wchar_t *)data.outbuf == L'\0')
+      if (data.outbuf != outbuf && *(wchar_t *)outbuf == L'\0')
 	{
 	  /* The converted character is the NUL character.  */
 	  assert (__mbsinit (data.statep));