not equal, the command line arguments are wrong. E.g.:
$./gcore /bin/sh 1761
$ ./gcore /usr/tmp/chroot/bin/sh 1761
gcore: The executable /usr/tmp/chroot/bin/sh does not belong to process 1761!
Text segment size (in bytes): executable 303104, process 294912
Didn't fix the alignment of the output fields on alpha where addresses
require 16 characters to print.
Added a dummy field to the pt_u union to help the alpha compiler align
the u_sa field in a suiable way.
the diff is attached below. This is done on the 3.0 source-tree.
I have test this on 2.2-stable before, but I don't have a 3.0 machine
right now.
This patch is mainly to make libc support BIG5 encoding, thus add
zh_TW.BIG5 locale to 3.0.
Submitted by: Chen Hsiung Chan <frankch@waru.life.nthu.edu.tw>
but flex still generates "#include <FlexLexer.h". As a result,
C++ sources flex generates failed to be compiled.
PR: 7575
Reviewed by: phk
Submitted by: MOROHOSHI Akihiko <moro@remus.dti.ne.jp>
Add functionality for support for more than 4 subfields within gcos. chsh,
chpass etc did not parse beyond the 4th field previously and so truncated
gcos on updating the database.
I hope some other people might find them useful. They are for
zh_CN.EUC (GB) only. I'm not familiar with the BIG5 encoding,
so I could only hope someone else would fill the gap.
PR: 7310
Submitted by: Luoqi Chen <luoqi@chen.ml.org>
special functions have names containing dollar signs, and ignoring
them causes gprof to produce incorrect and sometimes bizarre results.
The comment in the original code said that dollar signs were excluded
because they are used in Pascal labels. That's not much of an
issue these days.
various adventure game data files.
from Allen Garvin <earendil@faeryland.tamu-commerce.edu>
Edited by Dave Chapeskie <dchapes@ddm.on.ca> Jun 28, 1998
PR: 7466
Reviewed by: phk
Submitted by: The Frobozz Magic Homing Pigeon Company
libc/gen/getpass.c. The old behaviour of blocking SIGINT and not
changing SIGQUIT was restored in rev.1.5 of getpass.c. The change
here completely restores the old behaviour of not supporting killing
login with keyboard signals (only) at the password prompt. There
is no reason to support this, since login can be exited normally
by typing a couple of ^D's. Login certainly shouldn't dump core
in response to user input. Previously, SIGQUIT killed login
immediately but SIGINT killed it only after the password was
entered.
PR: 7444
PR: bin/5721
Submitted by: Oliver Fromme <oliver.fromme@heim3.tu-clausthal.de>
Also, add "volatile" to a variable modified by signal handlers (coincidentally,
the same variable involved in the above fix, although this isn't related
to the reported problem).
