htop/Process.h

180 lines
4.1 KiB
C
Raw Normal View History

2006-03-04 18:16:49 +00:00
#ifndef HEADER_Process
#define HEADER_Process
/*
htop - Process.h
2015-03-21 19:52:54 +00:00
(C) 2004-2015 Hisham H. Muhammad
(C) 2020 Red Hat, Inc. All Rights Reserved.
Released under the GNU GPLv2, see the COPYING file
2006-03-04 18:16:49 +00:00
in the source distribution for its full text.
*/
#include <stdbool.h>
#include <sys/types.h>
#include "Object.h"
#include "RichString.h"
2015-05-20 02:30:11 +00:00
#ifdef __ANDROID__
#define SYS_ioprio_get __NR_ioprio_get
#define SYS_ioprio_set __NR_ioprio_set
#endif
#define PROCESS_FLAG_IO 0x0001
typedef enum ProcessFields {
2016-05-30 15:22:07 +00:00
NULL_PROCESSFIELD = 0,
PID = 1,
COMM = 2,
STATE = 3,
PPID = 4,
PGRP = 5,
SESSION = 6,
TTY_NR = 7,
TPGID = 8,
MINFLT = 10,
MAJFLT = 12,
PRIORITY = 18,
NICE = 19,
STARTTIME = 21,
2015-03-17 02:01:48 +00:00
PROCESSOR = 38,
M_SIZE = 39,
M_RESIDENT = 40,
ST_UID = 46,
PERCENT_CPU = 47,
PERCENT_MEM = 48,
USER = 49,
TIME = 50,
NLWP = 51,
TGID = 52,
} ProcessField;
2006-03-04 18:16:49 +00:00
typedef struct ProcessPidColumn_ {
int id;
2020-08-20 19:58:14 +00:00
const char* label;
} ProcessPidColumn;
struct Settings_;
2006-03-04 18:16:49 +00:00
typedef struct Process_ {
Object super;
const struct Settings_* settings;
2006-03-04 18:16:49 +00:00
unsigned long long int time;
2010-02-25 01:43:18 +00:00
pid_t pid;
pid_t ppid;
pid_t tgid;
2006-03-04 18:16:49 +00:00
char* comm;
int commLen;
2006-03-04 18:16:49 +00:00
int indent;
int basenameOffset;
bool updated;
2006-03-04 18:16:49 +00:00
char state;
bool tag;
2010-06-17 19:02:03 +00:00
bool showChildren;
bool show;
unsigned int pgrp;
unsigned int session;
unsigned int tty_nr;
int tpgid;
uid_t st_uid;
2006-03-04 18:16:49 +00:00
unsigned long int flags;
2015-03-17 02:01:48 +00:00
int processor;
2014-02-27 19:35:22 +00:00
float percent_cpu;
float percent_mem;
const char* user;
2014-02-27 19:35:22 +00:00
2006-03-04 18:16:49 +00:00
long int priority;
long int nice;
long int nlwp;
2010-03-29 18:36:11 +00:00
char starttime_show[8];
time_t starttime_ctime;
2014-02-27 19:35:22 +00:00
long m_size;
long m_resident;
2014-02-27 19:35:22 +00:00
int exit_signal;
unsigned long int minflt;
unsigned long int majflt;
2006-03-04 18:16:49 +00:00
} Process;
typedef struct ProcessFieldData_ {
const char* name;
const char* title;
const char* description;
int flags;
} ProcessFieldData;
2006-03-04 18:16:49 +00:00
// Implemented in platform-specific code:
void Process_writeField(const Process* this, RichString* str, ProcessField field);
long Process_compare(const void* v1, const void* v2);
void Process_delete(Object* cast);
bool Process_isThread(const Process* this);
extern ProcessFieldData Process_fields[];
extern ProcessPidColumn Process_pidColumns[];
extern char Process_pidFormat[20];
2006-03-04 18:16:49 +00:00
typedef Process*(*Process_New)(const struct Settings_*);
typedef void (*Process_WriteField)(const Process*, RichString*, ProcessField);
2015-04-01 02:23:10 +00:00
typedef struct ProcessClass_ {
const ObjectClass super;
const Process_WriteField writeField;
} ProcessClass;
#define As_Process(this_) ((const ProcessClass*)((this_)->super.klass))
2015-03-17 02:01:48 +00:00
#define Process_getParentPid(process_) (process_->tgid == process_->pid ? process_->ppid : process_->tgid)
#define Process_isChildOf(process_, pid_) (process_->tgid == pid_ || (process_->tgid == process_->pid && process_->ppid == pid_))
#define Process_sortState(state) ((state) == 'I' ? 0x100 : (state))
Process.{h,c}: Use integer types that are more portable When building on a 32-bit system, the compiler warned that the following line uses a constant whose value is the overflow result of a compile-time computation: Process.c (line 109): } else if (number < 10000 * ONE_M) { Namely, this constant expression: 10000 * ONE_M was intended to produce the following value: 10485760000 However, the result overflowed to produce: 1895825408 The reason for this overflow is as follows: o The macros are expanded: 10000 * (ONE_K * ONE_K) 10000 * (1024L * 1024L) o The untyped constant expression "10000" is typed: 10000U * (1024L * 1024L) o The parenthesized expression is evaluated: 10000U * (1048576L) o The left operand ("10000U") is converted: 10000L * (1048576L) Unbound by integer sizes, that last multiplication would produce the following value: 10485760000 However, on a 32-bit machine, where a long is 32 bits (really 31 bits when talking about positive numbers), the maximum value that can be computed is 2**31-1: 2147483647 Consequently, the computation overflows. o The compiler produces a long int value that is the the result of overflow (10485760000 % 2**31): 1895825408L Actually, I think this overflow is implementation-defined, so it's not even a portable description of what happens. The solution is to use a long long int (or, even better, an unsigned long long int) type for the constant expression; the C standard mandates a sufficiently large maximum value for such types. Hence, the following change is made to the bad line: - } else if (number < 10000 * ONE_M) { + } else if (number < 10000ULL * ONE_M) { However, the whole line is now patently silly, because the variable "number" is typed "unsigned long", and so it will always be less than the constant expression (the compiler will warn about this, too). Hence, "number" must be typed "unsigned long long"; however, this necessitates changing all of the string formats from something like "%lu" to something like "%llu". Et voila! This commit is born. Then, for the sake of completeness, the declared types of the constant-expression macros are updated: o ONE_K is made unsigned (a "UL" instead of "L") o ONE_T is computed by introducing "1ULL *" o Similar changes are made for ONE_DECIMAL_{K,T} Also, a non-portable overflow-conversion to a signed value has been replaced with a portable comparison: - if ((long long) number == -1LL) { + if (number == ULLONG_MAX) { It might be worth reviewing the rest of the code for other cases where overflows are not handled correctly; even at runtime, it's often necessary to check for overflow unless such behavior is expected (especially for signed integer values, for which overflow has implementation-defined behavior).
2020-09-29 14:04:22 +00:00
#define ONE_K 1024UL
#define ONE_M (ONE_K * ONE_K)
#define ONE_G (ONE_M * ONE_K)
Process.{h,c}: Use integer types that are more portable When building on a 32-bit system, the compiler warned that the following line uses a constant whose value is the overflow result of a compile-time computation: Process.c (line 109): } else if (number < 10000 * ONE_M) { Namely, this constant expression: 10000 * ONE_M was intended to produce the following value: 10485760000 However, the result overflowed to produce: 1895825408 The reason for this overflow is as follows: o The macros are expanded: 10000 * (ONE_K * ONE_K) 10000 * (1024L * 1024L) o The untyped constant expression "10000" is typed: 10000U * (1024L * 1024L) o The parenthesized expression is evaluated: 10000U * (1048576L) o The left operand ("10000U") is converted: 10000L * (1048576L) Unbound by integer sizes, that last multiplication would produce the following value: 10485760000 However, on a 32-bit machine, where a long is 32 bits (really 31 bits when talking about positive numbers), the maximum value that can be computed is 2**31-1: 2147483647 Consequently, the computation overflows. o The compiler produces a long int value that is the the result of overflow (10485760000 % 2**31): 1895825408L Actually, I think this overflow is implementation-defined, so it's not even a portable description of what happens. The solution is to use a long long int (or, even better, an unsigned long long int) type for the constant expression; the C standard mandates a sufficiently large maximum value for such types. Hence, the following change is made to the bad line: - } else if (number < 10000 * ONE_M) { + } else if (number < 10000ULL * ONE_M) { However, the whole line is now patently silly, because the variable "number" is typed "unsigned long", and so it will always be less than the constant expression (the compiler will warn about this, too). Hence, "number" must be typed "unsigned long long"; however, this necessitates changing all of the string formats from something like "%lu" to something like "%llu". Et voila! This commit is born. Then, for the sake of completeness, the declared types of the constant-expression macros are updated: o ONE_K is made unsigned (a "UL" instead of "L") o ONE_T is computed by introducing "1ULL *" o Similar changes are made for ONE_DECIMAL_{K,T} Also, a non-portable overflow-conversion to a signed value has been replaced with a portable comparison: - if ((long long) number == -1LL) { + if (number == ULLONG_MAX) { It might be worth reviewing the rest of the code for other cases where overflows are not handled correctly; even at runtime, it's often necessary to check for overflow unless such behavior is expected (especially for signed integer values, for which overflow has implementation-defined behavior).
2020-09-29 14:04:22 +00:00
#define ONE_T (1ULL * ONE_G * ONE_K)
2006-03-04 18:16:49 +00:00
Process.{h,c}: Use integer types that are more portable When building on a 32-bit system, the compiler warned that the following line uses a constant whose value is the overflow result of a compile-time computation: Process.c (line 109): } else if (number < 10000 * ONE_M) { Namely, this constant expression: 10000 * ONE_M was intended to produce the following value: 10485760000 However, the result overflowed to produce: 1895825408 The reason for this overflow is as follows: o The macros are expanded: 10000 * (ONE_K * ONE_K) 10000 * (1024L * 1024L) o The untyped constant expression "10000" is typed: 10000U * (1024L * 1024L) o The parenthesized expression is evaluated: 10000U * (1048576L) o The left operand ("10000U") is converted: 10000L * (1048576L) Unbound by integer sizes, that last multiplication would produce the following value: 10485760000 However, on a 32-bit machine, where a long is 32 bits (really 31 bits when talking about positive numbers), the maximum value that can be computed is 2**31-1: 2147483647 Consequently, the computation overflows. o The compiler produces a long int value that is the the result of overflow (10485760000 % 2**31): 1895825408L Actually, I think this overflow is implementation-defined, so it's not even a portable description of what happens. The solution is to use a long long int (or, even better, an unsigned long long int) type for the constant expression; the C standard mandates a sufficiently large maximum value for such types. Hence, the following change is made to the bad line: - } else if (number < 10000 * ONE_M) { + } else if (number < 10000ULL * ONE_M) { However, the whole line is now patently silly, because the variable "number" is typed "unsigned long", and so it will always be less than the constant expression (the compiler will warn about this, too). Hence, "number" must be typed "unsigned long long"; however, this necessitates changing all of the string formats from something like "%lu" to something like "%llu". Et voila! This commit is born. Then, for the sake of completeness, the declared types of the constant-expression macros are updated: o ONE_K is made unsigned (a "UL" instead of "L") o ONE_T is computed by introducing "1ULL *" o Similar changes are made for ONE_DECIMAL_{K,T} Also, a non-portable overflow-conversion to a signed value has been replaced with a portable comparison: - if ((long long) number == -1LL) { + if (number == ULLONG_MAX) { It might be worth reviewing the rest of the code for other cases where overflows are not handled correctly; even at runtime, it's often necessary to check for overflow unless such behavior is expected (especially for signed integer values, for which overflow has implementation-defined behavior).
2020-09-29 14:04:22 +00:00
#define ONE_DECIMAL_K 1000UL
2014-02-27 19:35:22 +00:00
#define ONE_DECIMAL_M (ONE_DECIMAL_K * ONE_DECIMAL_K)
#define ONE_DECIMAL_G (ONE_DECIMAL_M * ONE_DECIMAL_K)
Process.{h,c}: Use integer types that are more portable When building on a 32-bit system, the compiler warned that the following line uses a constant whose value is the overflow result of a compile-time computation: Process.c (line 109): } else if (number < 10000 * ONE_M) { Namely, this constant expression: 10000 * ONE_M was intended to produce the following value: 10485760000 However, the result overflowed to produce: 1895825408 The reason for this overflow is as follows: o The macros are expanded: 10000 * (ONE_K * ONE_K) 10000 * (1024L * 1024L) o The untyped constant expression "10000" is typed: 10000U * (1024L * 1024L) o The parenthesized expression is evaluated: 10000U * (1048576L) o The left operand ("10000U") is converted: 10000L * (1048576L) Unbound by integer sizes, that last multiplication would produce the following value: 10485760000 However, on a 32-bit machine, where a long is 32 bits (really 31 bits when talking about positive numbers), the maximum value that can be computed is 2**31-1: 2147483647 Consequently, the computation overflows. o The compiler produces a long int value that is the the result of overflow (10485760000 % 2**31): 1895825408L Actually, I think this overflow is implementation-defined, so it's not even a portable description of what happens. The solution is to use a long long int (or, even better, an unsigned long long int) type for the constant expression; the C standard mandates a sufficiently large maximum value for such types. Hence, the following change is made to the bad line: - } else if (number < 10000 * ONE_M) { + } else if (number < 10000ULL * ONE_M) { However, the whole line is now patently silly, because the variable "number" is typed "unsigned long", and so it will always be less than the constant expression (the compiler will warn about this, too). Hence, "number" must be typed "unsigned long long"; however, this necessitates changing all of the string formats from something like "%lu" to something like "%llu". Et voila! This commit is born. Then, for the sake of completeness, the declared types of the constant-expression macros are updated: o ONE_K is made unsigned (a "UL" instead of "L") o ONE_T is computed by introducing "1ULL *" o Similar changes are made for ONE_DECIMAL_{K,T} Also, a non-portable overflow-conversion to a signed value has been replaced with a portable comparison: - if ((long long) number == -1LL) { + if (number == ULLONG_MAX) { It might be worth reviewing the rest of the code for other cases where overflows are not handled correctly; even at runtime, it's often necessary to check for overflow unless such behavior is expected (especially for signed integer values, for which overflow has implementation-defined behavior).
2020-09-29 14:04:22 +00:00
#define ONE_DECIMAL_T (1ULL * ONE_DECIMAL_G * ONE_DECIMAL_K)
2014-02-27 19:35:22 +00:00
void Process_setupColumnWidths(void);
Process.{h,c}: Use integer types that are more portable When building on a 32-bit system, the compiler warned that the following line uses a constant whose value is the overflow result of a compile-time computation: Process.c (line 109): } else if (number < 10000 * ONE_M) { Namely, this constant expression: 10000 * ONE_M was intended to produce the following value: 10485760000 However, the result overflowed to produce: 1895825408 The reason for this overflow is as follows: o The macros are expanded: 10000 * (ONE_K * ONE_K) 10000 * (1024L * 1024L) o The untyped constant expression "10000" is typed: 10000U * (1024L * 1024L) o The parenthesized expression is evaluated: 10000U * (1048576L) o The left operand ("10000U") is converted: 10000L * (1048576L) Unbound by integer sizes, that last multiplication would produce the following value: 10485760000 However, on a 32-bit machine, where a long is 32 bits (really 31 bits when talking about positive numbers), the maximum value that can be computed is 2**31-1: 2147483647 Consequently, the computation overflows. o The compiler produces a long int value that is the the result of overflow (10485760000 % 2**31): 1895825408L Actually, I think this overflow is implementation-defined, so it's not even a portable description of what happens. The solution is to use a long long int (or, even better, an unsigned long long int) type for the constant expression; the C standard mandates a sufficiently large maximum value for such types. Hence, the following change is made to the bad line: - } else if (number < 10000 * ONE_M) { + } else if (number < 10000ULL * ONE_M) { However, the whole line is now patently silly, because the variable "number" is typed "unsigned long", and so it will always be less than the constant expression (the compiler will warn about this, too). Hence, "number" must be typed "unsigned long long"; however, this necessitates changing all of the string formats from something like "%lu" to something like "%llu". Et voila! This commit is born. Then, for the sake of completeness, the declared types of the constant-expression macros are updated: o ONE_K is made unsigned (a "UL" instead of "L") o ONE_T is computed by introducing "1ULL *" o Similar changes are made for ONE_DECIMAL_{K,T} Also, a non-portable overflow-conversion to a signed value has been replaced with a portable comparison: - if ((long long) number == -1LL) { + if (number == ULLONG_MAX) { It might be worth reviewing the rest of the code for other cases where overflows are not handled correctly; even at runtime, it's often necessary to check for overflow unless such behavior is expected (especially for signed integer values, for which overflow has implementation-defined behavior).
2020-09-29 14:04:22 +00:00
void Process_humanNumber(RichString* str, unsigned long long number, bool coloring);
void Process_colorNumber(RichString* str, unsigned long long number, bool coloring);
void Process_printTime(RichString* str, unsigned long long totalHundredths);
void Process_fillStarttimeBuffer(Process* this);
void Process_outputRate(RichString* str, char* buffer, int n, double rate, int coloring);
void Process_display(const Object* cast, RichString* out);
void Process_done(Process* this);
2006-03-04 18:16:49 +00:00
2020-10-05 11:19:50 +00:00
extern const ProcessClass Process_class;
void Process_init(Process* this, const struct Settings_* settings);
void Process_toggleTag(Process* this);
2006-03-04 18:16:49 +00:00
bool Process_setPriority(Process* this, int priority);
2006-03-04 18:16:49 +00:00
bool Process_changePriorityBy(Process* this, Arg delta);
2012-10-04 23:59:45 +00:00
bool Process_sendSignal(Process* this, Arg sgn);
2006-03-04 18:16:49 +00:00
long Process_pidCompare(const void* v1, const void* v2);
2006-03-04 18:16:49 +00:00
#endif