mirror of
https://sourceware.org/git/glibc.git
synced 2025-01-03 00:10:10 +00:00
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.
This commit is contained in:
Roland McGrath
parent
613a76ff52
commit
41f27456ac
@ -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.
|
||||
|
||||
66
FAQ
66
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.
|
||||
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. 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).
|
||||
* _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
|
||||
|
||||
@ -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;
|
||||
|
||||
|
||||
@ -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))
|
||||
|
||||
@ -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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user