Fri May 24 17:30:50 1996 Roland McGrath <roland@delasyd.gnu.ai.mit.edu>

	* login/pututline_r.c: Use struct assignment instead of memcpy.

	* login/getutline_r.c: Use strncmp instead of comparing two pointers
	that will only be equal if you are overwriting the data and screwing
	yourself anyway.

5 files changed, 71 insertions, 56 deletions

diff --git a/ChangeLog b/ChangeLog
index 3bf5a87..3c637be 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+Fri May 24 17:30:50 1996  Roland McGrath  <roland@delasyd.gnu.ai.mit.edu>
+
+	* login/pututline_r.c: Use struct assignment instead of memcpy.
+
+	* login/getutline_r.c: Use strncmp instead of comparing two pointers
+	that will only be equal if you are overwriting the data and screwing
+	yourself anyway.
+
 Fri May 24 02:31:36 1996  Ulrich Drepper  <drepper@cygnus.com>
 
 	* sysdeps/unix/sysv/linux/speed.c: Add new speed value 460800.
diff --git a/FAQ b/FAQ
index 91e531d..9ebd95d 100644
--- a/FAQ
+++ b/FAQ
@@ -1,8 +1,8 @@
 		Frequently Asked Question on GNU C Library
 
-As every FAQ this one also tries to answer the questions the user
-might when using the pacakge.  Please make sure you read this before
-sending questions/bug reports to the maintainers.
+As every FAQ this one also tries to answer questions the user might have
+when using the pacakge.  Please make sure you read this before sending
+questions or bug reports to the maintainers.
 
 The GNU C Library is very complex.  The building process exploits the
 features available in tools generally available.  But many things can
@@ -11,17 +11,17 @@ understand because it has to be portable but on the other hand must be
 fast.  But you need not understand the details to use GNU C Library.
 This will only be necessary if you intend to contribute or change it.
 
-If you have any question which you think might be worth answered in
-this document let me know.
+If you have any questions you think should be answered in this document,
+please let me know.
 
 						  --drepper@cygnus.com
 
 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q1]	``What systems the GNU C Library runs on?''
+[Q1]	``What systems does the GNU C Library run on?''
 
-[Q2]	``What compiler do I need to translate GNU libc?''
+[Q2]	``What compiler do I need to build GNU libc?''
 
-[Q3]	``When starting make I get only errors messages.
+[Q3]	``When starting make I get only error messages.
 	  What's wrong?''
 
 [Q4]	``After I changed configure.in I get `Autoconf version X.Y.
@@ -39,7 +39,7 @@ this document let me know.
 
 
 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q1]	``What systems the GNU C Library runs on?''
+[Q1]	``What systems does the GNU C Library run on?''
 
 [A1] {UD} This is difficult to answer.  The file `README' lists the
 architectures GNU libc is known to run *at some time*.  This does not
@@ -57,12 +57,11 @@ some success reports first.
 If you have a system not listed above (or in the `README' file) and
 you are really interested in porting it, contact
 
-	Roland McGrath		<roland@gnu.ai.mit.edu>
-or	Ulrich Drepper		<drepper@cygnus.com>
+	<bug-glibc@prep.ai.mit.edu>
 
 
 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-[Q2]	``What compiler do I need to translate GNU libc?''
+[Q2]	``What compiler do I need to build GNU libc?''
 
 [A2] {UD} It is (almost) impossible to compile GNU C Library using a
 different compiler than GNU CC.  A lot of extensions of GNU CC are
@@ -111,6 +110,9 @@ will not get a really ISO C compliant C library.  Generally speaking
 you should use the GNU binutils if they provide at least the same
 functionality as your system's tools.
 
+Always get the newest release of GNU binutils available.
+Older releases are known to have bugs that affect building the GNU C library.
+
 
 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
 [Q6]	``Do I need some more things to compile GNU C Library?''
@@ -125,7 +127,7 @@ functionality as your system's tools.
 * plenty of time (approx 1h for i386-linux on i586@133 or 2.5h or
   i486@66).
 
-  If you have some more interested measurements let me know.
+  If you are interested in some more measurements let me know.
 
 
 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
@@ -146,7 +148,7 @@ symbols:
    is linked against libm, too.)
 
 Generally, you should make sure you find a real program which produces
-errors while linking.
+errors while linking before deciding there is a problem.
 
 
 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
@@ -154,21 +156,19 @@ errors while linking.
 	  the old Linux based GNU libc.  Why isn't it like this?''
 
 [A8] {DMT} Not every extension in Linux libc's history was well
-thought.  In fact it had a lot of problems with standard compliance
-and cleanliness.  With the introduction of a new version number these
-errors now can be corrected.  The following list shows a list of the
-know source code incompatibilities.
-
-* _GNU_SOURCE: glibc does not automatically define _GNU_SOURCE.  Thus,
-  if a program depends on GNU extensions, it is necessary
-  to compile it with C compiler option -D_GNU_SOURCE.  This difference
-  normally mainfests itself in the form of missing prototypes and/or
-  data type definitions.  Thus, if you get such errors, the first thing you
-  should do is grep the header files in /usr/include and /usr/include/sys
-  to check whether the functions are really missing or whether it is
-  just necessary to add a define of _GNU_SOURCE.  Similar comments apply
-  to _BSD_SOURCE, _POSIX_SOURCE, _SVID_SOURCE etc (see
-  /usr/include/features.h).
+thought-out.  In fact it had a lot of problems with standards compliance
+and with cleanliness.  With the introduction of a new version number these
+errors now can be corrected.  Here is a list of the known source code
+incompatibilities:
+
+* _GNU_SOURCE: glibc does not automatically define _GNU_SOURCE.  Thus, if a
+  program depends on GNU extensions, it is necessary to compile it with C
+  compiler option -D_GNU_SOURCE, or better, to put `#define _GNU_SOURCE' at
+  the beginning of your source files, before any C library header files are
+  included.  This difference normally mainfests itself in the form of
+  missing prototypes and/or data type definitions.  Thus, if you get such
+  errors, the first thing you should do is try defining _GNU_SOURCE and see
+  if that makes the problem go away.
 
 * reboot(): GNU libc sanitizes the interface of reboot() to be more
   compatible with the interface used on other OSes.  In particular,
@@ -194,16 +194,12 @@ know source code incompatibilities.
 
        syscall name:	wrapper name:	declaring header file:
        -------------	-------------	----------------------
-       bdflush		bdflush		<unistd.h>
+       bdflush		bdflush		???
        create_module	create_module	<sys/module.h>
        delete_module	delete_module	<sys/module.h>
        get_kernel_syms	get_kernel_syms	<sys/module.h>
        init_module	init_module	<sys/module.h>
-       syslog		ksyslog_ctl	<unistd.h>
-
-  To get the Linux-specific declarations in <unistd.h>, you'll need
-  to define C pre-processor macro _LINUX_SOURCE during compilation.
-
+       syslog		ksyslog_ctl	???
 
 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
 
@@ -212,6 +208,8 @@ Answers were given by:
 {UD} Ulrich Drepper, <drepper@cygnus.com>
 {DMT} David Mosberger-Tang, <davidm@AZStarNet.com>
 
+Amended by:
+{RM} Roland McGrath <roland@gnu.ai.mit.edu>
 
 Local Variables:
  mode:text
diff --git a/login/getutline_r.c b/login/getutline_r.c
index 62c8c2f..84c77cb 100644
--- a/login/getutline_r.c
+++ b/login/getutline_r.c
@@ -53,7 +53,8 @@ getutline_r (const struct utmp *line, struct utmp **utmp,
       /* Update position pointer.  */
       utmp_data->loc_utmp += sizeof (struct utmp);
     }
-  while (line->ut_line != utmp_data->ubuf.ut_line);
+  while (strncmp (line->ut_line, utmp_data->ubuf.ut_line,
+		  sizeof line->ut_line));
 
   *utmp = &utmp_data->ubuf;
 
diff --git a/login/pututline_r.c b/login/pututline_r.c
index 365a376..92ba8fb 100644
--- a/login/pututline_r.c
+++ b/login/pututline_r.c
@@ -44,9 +44,9 @@ pututline_r (const struct utmp *utmp_ptr, struct utmp_data *utmp_data)
       struct utmp_data *data_tmp = alloca (sizeof (utmp_data));
       struct utmp *dummy;
 
-      memcpy (data_tmp, utmp_data, sizeof (utmp_data));
+      *data_tmp = *utmp_data;
       utmp_data = data_tmp;
-      
+
       if (getutid_r (utmp_ptr, &dummy, utmp_data) < 0)
 	{
 	  if (errno != ESRCH)
@@ -66,7 +66,7 @@ pututline_r (const struct utmp *utmp_ptr, struct utmp_data *utmp_data)
 
   /* XXX An alternative solution would be to call an SUID root program
      which write the new value.  */
-  
+
   /* Try to lock the file.  */
   if (flock (utmp_data->ut_fd, LOCK_EX | LOCK_NB) < 0 && errno != ENOSYS)
     {
@@ -76,7 +76,7 @@ pututline_r (const struct utmp *utmp_ptr, struct utmp_data *utmp_data)
       /* This time we ignore the error.  */
       (void) flock (utmp_data->ut_fd, LOCK_EX | LOCK_NB);
     }
-  
+
   /* Write the new data.  */
   if (write (utmp_data->ut_fd, &utmp_data->ubuf, sizeof (struct utmp))
       != sizeof (struct utmp))
diff --git a/manual/maint.texi b/manual/maint.texi
index 84ff95e..8d2610d 100644
--- a/manual/maint.texi
+++ b/manual/maint.texi
@@ -247,11 +247,11 @@ sparc-sun-solaris2.@var{n}
 sparc-sun-sunos4.@var{n}
 @end smallexample
 
-Each case of @samp{i@var{x}86} can be @samp{i386}, @samp{i486}, or
-@samp{i586}.  All of those configurations produce a library that can run
-on any of these processors.  The library will be optimized for the
-specified processor, but will not use instructions not available on all
-of them.
+Each case of @samp{i@var{x}86} can be @samp{i386}, @samp{i486},
+@samp{i586}, or @samp{i686}..  All of those configurations produce a
+library that can run on any of these processors.  The library will be
+optimized for the specified processor, but will not use instructions not
+available on all of them.
 
 While no other configurations are supported, there are handy aliases for
 these few.  (These aliases work in other GNU software as well.)
@@ -329,8 +329,9 @@ But what they do is fairly straightforward, and only requires that you
 define a few variables in the right places.
 
 The library sources are divided into subdirectories, grouped by topic.
+
 The @file{string} subdirectory has all the string-manipulation
-functions, @file{stdio} has all the standard I/O functions, etc.
+functions, @file{math} has all the mathematical functions, etc.
 
 Each subdirectory contains a simple makefile, called @file{Makefile},
 which defines a few @code{make} variables and then includes the global
@@ -370,7 +371,9 @@ run all the test programs.  If a test program needs input, put the test
 data in a file called @file{@var{test-program}.input}; it will be given to
 the test program on its standard input.  If a test program wants to be
 run with arguments, put the arguments (all on a single line) in a file
-called @file{@var{test-program}.args}.@refill
+called @file{@var{test-program}.args}.  Test programs should exit with
+zero status when the test passes, and nonzero status when the test
+indicates a bug in the library or error in building.
 
 @item others
 The names of ``other'' programs associated with this section of the
@@ -459,17 +462,22 @@ So the final list is @file{unix/bsd/vax unix/bsd unix/inet unix posix}.
 and @file{stub}.  These two are always implicitly appended to the list
 of subdirectories (in that order), so you needn't put them in an
 @file{Implies} file, and you should not create any subdirectories under
-them.  @file{generic} is for things that can be implemented in
-machine-independent C, using only other machine-independent functions in
-the C library.  @file{stub} is for @dfn{stub} versions of functions
-which cannot be implemented on a particular machine or operating system.
-The stub functions always return an error, and set @code{errno} to
-@code{ENOSYS} (Function not implemented).  @xref{Error Reporting}.
+them intended to be new specific categories.  @file{generic} is for
+things that can be implemented in machine-independent C, using only
+other machine-independent functions in the C library.  @file{stub} is
+for @dfn{stub} versions of functions which cannot be implemented on a
+particular machine or operating system.  The stub functions always
+return an error, and set @code{errno} to @code{ENOSYS} (Function not
+implemented).  @xref{Error Reporting}.
 
 A source file is known to be system-dependent by its having a version in
-@file{generic} or @file{stub}; every system-dependent function should
-have either a generic or stub implementation (there is no point in
-having both).
+@file{generic} or @file{stub}; every generally-available function whose
+implementation is system-dependent in should have either a generic or
+stub implementation (there is no point in having both).  Some rare functions
+are only useful on specific systems and aren't defined at all on others;
+these do not appear anywhere in the system-independent source code or makefiles
+(including the @file{generic} and @file{stub} directories), only in the
+system-dependent @file{Makefile} in the specific system's subdirectory.
 
 If you come across a file that is in one of the main source directories
 (@file{string}, @file{stdio}, etc.), and you want to write a machine- or