Commit Graph

8 Commits

Author SHA1 Message Date
Craig Small
aa41c309dd kill: -l space between name parses correctly
This was supposed to be just a cherry-pick of the referenced
commit. However there were two problems:
 1. kill code was moved out to its own file
 2. strtosig() had a latent bug where signal numbers were not
 converted to names.

Original note:
kill -lHUP would work correctly, but kill -l HUP would not.

The list option in kill was hit by a quirk of getopt_long where an
option with an optional argument would not attempt to get the argument
beyond the space, even though a mandatory argument would do that.

The fix is a kludge to scan to the next argument and if it looks
like something we can use, use it. Lucky for us, the list option is
one where parsing can stop immediately.

Thanks to Brian Vandenberg for the way forward.

References:
 http://stackoverflow.com/questions/1052746/getopt-does-not-parse-optional-arguments-to-parameters
 https://bugs.debian.org/854407
 commit 537cea324b121f54744369425332c256aa84a181
2017-05-22 22:15:59 +10:00
Jim Warner
618a813baa misc: eliminate all those remaining gcc -Wall warnings
Reference(s):
proc/readproc.c: In function 'statm2proc'
proc/readproc.c:600:9: warning: variable 'num' set but not used [-Wunused-but-set-variable]

proc/stat.c: In function 'stat_derive_unique':
proc/stat.c:429:1: warning: no return statement in function returning non-void [-Wreturn-type]

ps/parser.c: In function 'arg_type':
ps/parser.c:1098:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
ps/parser.c:1099:34: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'

lib/signals.c: In function 'strtosig':
lib/signals.c:243:9: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
lib/signals.c:245:13: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'

slabtop.c: In function 'print_summary':
slabtop.c:223:29: warning: unused variable 'stats' [-Wunused-variable]

watch.c: In function 'process_ansi':
watch.c:232:5: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
watch.c:235:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-22 21:38:10 +10:00
Olof Sivertsson
95ed10ff43 kill: Fix free() with bad pointer on SIG-prefixed signal-name
kill -l SIGHUP (or any other signal-name prefixed with "SIG")
would cause free() to be called with a bad pointer instead of
a pointer to what was allocated. Fix this and add test-case.
2016-09-11 09:58:55 +10:00
Jon Boden
6f8c101e2e library: Don't use SIGPWR on FreeBSD
FreeBSD doesn't have SIGPWR so makes no sense in warning and assuming
its 29.

Picked from master, but the file has moved from proc/sig.c to
library/signals.c

References:
 commit 8abd0c92ab
 https://bugs.debian/org/832148

Signed-off-by: Craig Small <csmall@enc.com.au>
2016-08-28 19:19:05 +10:00
Craig Small
d2df396ba9 misc: Few more resource leak fixes
free after malloc in signals.c
closedir after opendir in diskstat
2016-05-03 21:58:13 +10:00
Craig Small
6586f9f9ce skill: fix command line with signal, again
Application of master patch d1d2ccf

Original by Filipe Brandenburger <filbranden@google.com>

Signed-off-by: Craig Small <csmall@enc.com.au>
2016-04-11 20:59:48 +10:00
Craig Small
f65121ef74 kill: split out from skill/snice
The first part of fixing skill/snice to use the library instead
of directly readdir()ing /proc which is what it does now.

Remove the kill code from the skill/snice code and put common
elements into lib/signals.c Not 100% sure that is the right
destination instead of a new lib file, but ok for now.

kill shares some parsing logic with skill/snice but mainly
around signal specifications. The "do it" code is very different.

Signed-off-by: Craig Small <csmall@enc.com.au>
2015-09-26 09:13:13 +10:00
Craig Small
56399212c8 library: Remove signal name from library
Procps library previously held functions that were about either
listing or finding signal names. These are not really the right
location for a library about reading procfs.

This patch handles signal related functions in two ways:

For functions purely found in skill, these have been moved back
into this binary as they are used nowhere else.

For functions used across the binaries, these have been moved
into include/signals.h and lib/signals.c. Besides formatting,
these functions are largely the same.

To assist the skill functions, two functions to access the
signal map array have been added to lib/signals.c
2015-06-29 21:52:51 +10:00