One of the check_include_file checks in ConkyPlatformChecks should
not have been changed to check_include_files because the latter
takes 2 arguments and this call gives 3 (and doens't work right
without the third).
Fixes #162 by changing CheckInlcudeFile to
CheckIncludeFiles so that CMake can correctly include
the module. Change calls to check_include_file to
check_include_files.
I ran cppcheck on a whim while trying to debug #103 and it found these possible
memory corruptions. They all seem to be buffers that were made one byte too
small (leaving out the byte for the C-string null terminator).
When we parse /proc/<pid>/* in order to populate the process struct, it isn't
necessary to try to remove any instance of "kdeinit: " anymore (IMO). Here is
why:
* If the user chooses to display full command lines (top_name_verbose = true),
then we should show full command lines without stripping useful info.
* The new basename entry already has a stripped down command. For example, if
the command line is "kdeinit4: kded4 [kdeinit]", then basename is "kded4".
* The code does not account for "kdeinit{4,5}: ", resulting in undesired
behavior, e.g. "kdeinit4: kded4 [kdeinit]" becomes "kdeinit4:".
* The code does not account for NUL separated arguments.
* The code opens /proc/<pid>/cmdline a second time, so this commit is a minor
optimization.
I think it is best to remove this code altogether. If anyone disagrees, please
comment or send me some hate mail with reasons why we should keep it. The commit
is easy enough to revert. :)
The new top_name_verbose option works in most cases, but it will fail if the
executable name contains spaces. Trying to parse command lines from
/proc/<pid>/* turned out to be quite complex due to the many edge cases. My
solution, once again, is to fall back to 1.9.x behavior. If top_name_verbose is
true, use the full command line. Otherwise, use basename.
Fixes #131.
Currently, in order to match a running process with ${if_running}, a user needs
to specify the full command line plus arguments in conky.conf. This commit keeps
that behavior and adds a fallback that is equivalent to the 1.9.x bevahior,
namely matching against the executable name contained in /proc/<pid>/stat.
This completes the fix for #121.
Since we now store a full command line for each process, a few problems are
apparent. For example, the names displayed by ${top ...} are verbose. This has
been partially addressed by the top_name_verbose option, but it is broken
whenever an executable name contains spaces. Another example is ${if_running},
which only matches the input if it exactly matches the entire command line.
This commit adds a basename (i.e. executable filename) entry to the process
struct. The intention is to store the executable filename from /proc/<pid>/stat,
which was the old 1.9.x behavior. This way, we have the best of both worlds.
Those who like the full command line can have it, and those who prefer the old
way can be satisfied too.
According to proc(5), /proc/<pid>/cmdline is supposed to have a NUL between each
argument, plus an additional NUL at the end. Instead of replacing each NUL with
a space, just replace the ones between arguments and ignore the rest.
Partial fix for #121.
lua_gettable returns an int instead of void in Lua 5.3, so provide a
backwards-compatible overload of safe_misc_trampoline to account for this.
Tested with Lua 5.2 and 5.3.
This change does not address other compilation issues related to Lua bindings
for cairo, imlib2, and rsvg.
Fixes #90 and part of #100.
Note: This may not be the correct solution, it depends on the author's intention. Maybe he wanted to keep the headers from the previous call (in other words if there are no new headers use the old ones) and didn't realize they weren't copied in the handle, in which case he'll have to save the headers instead of above.
There are 2 variants of strerror_r, GNU extension and a POSIX variant.
Use the more portable POSIX variant.
Also fix a potensial stack-use-after-return bug, instead of relying on
undefined behavoir in GNU libc implementation. The strerror_r manpage
says:
> This may be either a pointer to a string that the function stores in
> buf, or a pointer to some (immutable) static string (in which case buf
> is unused).
So it does not guarantee that it returns a pointer to some (immutable)
static string. It might return a pointer to "buf", in which case we get
a stack-use-after-return bug.
We fix this by declaring a thread local static buffer which we always
return.
