GitLab

Closes #480.

Use a SOURCE_DATA_EPOCH friendly date.
Suggested by @fasterit in #476.

Rename Meter.setValues() functions to updateValues()

Rationale (copied from htop issue #471):
The function name "setValues" is misleading. For most OOP (object-
oriented programming) contexts, setXXX functions mean they will change
some member variables of an object into something specified in
function arguments. But in the *Meter_setValues() case, the new values
are not from the arguments, but from a hard-coded source. The caller
is not supposed to change the values[] to anything it likes, but
rather to "update" the values from the source. Hence, updateValues is
a better name for this family of functions.

Remove needless allocation error conditions

These allocations were converted to use xMalloc et al. and no longer
need error checks.

BarMeterMode_draw() minor code improvement

Removed a loop that sets the bar[] buffer with spaces and merged that
task to the snprintf() call just below. No need for the barOffset
variable. Display behavior is unchanged.

Size comparision (when compiled on Ubuntu 14.04 64-bit):

    $ size htop.old htop.new
       text    data     bss     dec     hex filename
     137312   15112    3776  156200   26228 htop.old
     137216   15112    3776  156104   261c8 htop.new

Assert (Platform_meterTypes[0] == &CPUMeter_class)

Just assume Platform_meterTypes[0] is always &CPUMeter_class for every
platform. This removes a conditional in AvailableMetersPanel_new().

Also adds some comments about the logic here. Without assuming
Platform_meterTypes[0], the (int i=1) clause in this for loop will not
make sense. (I.e. Why not (int i=0)? )

Also replaced a sprintf() call with safer snprintf() in code further
below.

Explicit "maxItems" property of meters

Two changes in this commit:
- All meters now explicitly specify "maxItems" property, even for just
  1 item. (Exception is "container" CPU meter classes, which use
  CUSTOM_METERMODE.)
- "maxItems" being 0 is now allowed. This will let bar meters and graph
  meters render an empty meter.

calloc() allows 'nmemb' or 'size' to be zero, in which case NULL may be
returned. Letting htop die because of either argument being zero doesn't
make sense.

As a side note: As size_t is unsigned, compiler should be able to optimize
conditional (nmemb > 0 && size > 0) to (nmemb && size). This theorically
shouldn't increase code size too much.

Avoid overlapping key values defined by curses (Real fix).

Real fix for issue #438.

Closes #438.

Misc. OpenBSD tuneup and improvement

Improve error reporting on FreeBSD libkvm call

Merge branch 'openbsd-mem-used' of https://github.com/juanfra684/htop into juanfra684-openbsd-mem-used

Namely:

 o use malloc where an xCalloc slipped in

 o safeguard against an empty arg list - I don't think it's possible,
   but it would be potentially exploitable

 o we need to initialize the arg string to an empty string because we no
 longer use strlcpy(3)

 o annotate a tricky use of strlcpy(3)'s truncation

Including:

 o set *basenameEnd even in error cases (FreeBSD probably needs this)

 o use kvm_openfiles(3) rather than kvm_open(3) so that we can report
   errors (as with FreeBSD)

 o sanify the process argument list creation by using strlcat(3)

 o drop the pageSizeKb variable and use the PAGE_SIZE_KB macro directly,
   as the page size can't change anyway

 o clean up a few macros, add MINIMUM() and MAXIMUM() (should be
   mirrored to FreeBSD)

 o fix some syntax

 o add some useful comments

This involves switching from kvm_open(3) to kvm_openfiles(3). The only
difference is that the latter has saner error reporting (see the man
page for details). We can now fatally report the error rather than just
calling assert(3).

Add "p" to Help

Fix low CPU usage reporting in FreeBSD

Display them properly. Not fully convinced of the "no perm" message...

Once a process goes zombie on Linux, /proc/PID/cmdline
gets empty. So, when we detect it is a zombie we stop
reading this file.
For processes that were zombies before htop started,
there's no way to get the full name.
Closes #49.