diff options
| -rw-r--r-- | ChangeLog | 8 | ||||
| -rw-r--r-- | FAQ | 68 | ||||
| -rw-r--r-- | login/getutline_r.c | 3 | ||||
| -rw-r--r-- | login/pututline_r.c | 8 | ||||
| -rw-r--r-- | manual/maint.texi | 40 |
5 files changed, 71 insertions, 56 deletions
diff --git a/ChangeLog b/ChangeLog index 3bf5a87dff..3c637be4fe 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 91e531dbf1..9ebd95d7a5 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 62c8c2fd66..84c77cb244 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 365a37672e..92ba8fb308 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 84ff95e9c6..8d2610de2e 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 |