Currently we set inotify_fd to the value 0 when inotify_fd hasn't been
created yet, or after we close it. But 0 is a valid fd, and we check
for the value -1 to see if it's been initialized. So, if inotify
support is compiled in, but we disable_auto_reload, we can end up
closing fd 0. This can screw up various other things in weird ways,
including that exec'd processes appear to have an invalid stdin.
So, set inotify_fd to -1 to clear all of this up.
luamm is now able to be compiled with both lua 5.1 and 5.2 (assuming 5.2 has backward
compatibility features compiled in). It is my intention to always support at least two versions
of lua.
On systems, the buildprocess will complain:
[ 7%] Building CXX object src/CMakeFiles/conky.dir/c++wrap.cc.o
conky/src/c++wrap.cc: In function ‘std::string strerror_r(int)’:
conky/src/c++wrap.cc:66:37: warning: ignoring return value of ‘char* strerror_r(int, char*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
According to "man 3 strerror_r" the buffer used as 2nd arg is not always used, this patch also fixes that problem.
On systems with a strict compiler, the buildprocess will complain:
[ 70%] Building CXX object src/CMakeFiles/conky.dir/update-cb.cc.o
conky/src/update-cb.cc: In member function ‘void conky::priv::callback_base::stop()’:
conky/src/update-cb.cc:49:34: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result
This patch fixes this warning (and by doing this also checks if the write worked)
One problem is, that tolua/lua does not handle plain data pointers
properly. Therefore something like
local surface = cairo_image_surface_create_for_data(
imlib_image_get_data_for_reading_only(), ..
will fail using the lua bindings. Hence this wrapper, which adds
a function which be used to draw an imlib image to a cairo surface.
This also addresses another issue, drawing images with a transparent
background (e.g. gifs or pngs) to the cairo surface properly. Apparently
the image format of imlib is incompatible to cairos which uses
pre-multiplied data. This is also explained in the cairo documentation.
A fix for this issue is to blend the image with another alpha mask to
get the correct values. The code and explanation for this was taken from
http://lists.cairographics.org/archives/cairo/2008-March/013492.html
Executive Summary: This wrapper function can load (transparent) images
(e.g. gif or png) from a file by using imlib and draw them on a cairo
surface.
This wrapper functions should facilitate the handling of rsvg handles.
Especially unrefing with g_object_unref does not seem to work properly
using the lua bindings.
Add scratch files as a start: merge rsvg.h and rsvg-cairo.h.
Concatenate licenses of rsvg.h and rsvg-cairo.
Remove unnecessary defines, private structs, unused apis
(GIO/GdkPixbuf), etc.
Replace deprecated api functions with glib-object functions
Add headers for glib.h and librsvg/rsvg.h
Before, in the case of an unknown battery status (which often happens on my Sony VAIO laptop after waking from sleep), the buffer would be unterminated.
(Although, this memmove trick is a bit odd. It would probably be better to remove the memmove's and put a single buffer[1] = '\0'; at the end of the function).
Conky takes process names from /proc/<pid>/stat and it's limited to 16
chars in kernel. That obviously makes top_name_width option to work only
for decreasing name length. To obtain longer names we parse
/proc/<pid>/cmdline.
Not every process has cmdline, so we take both process names and choose
one we want to use. Like this:
- Get process name from /proc/<pid>/stat
- Get process cmdline from /proc/<pid>/cmdline
- Transform cmdline to a bit simpler form(i.e. "/usr/bin/python
/usr/bin/terminator" to "python /usr/bin/terminator"), keeping
the arguments(might be changed easily)
- Choose the one that is longer and use it
== common.cc ==
'result' can be uninitialized.
== conky.cc ==
strcpy()'s overlap: undefined behaviour. memmove()'s one is
defined.
== eve.cc ==
Some simplifications, and there are two leaks:
1. 'mySkill' could be leaked. So, let's make 'skill' point to it instead
of strdup()'ing the buffer.
2. 'output' could be leaked at l.390.
== freebsd.cc ==
Leak of 'freq_sysctl'.
== net_stat.cc ==
free() already null-checks, so we don't need to do it again.
== proc.cc ==
Leak.
Signed-off-by: Pavel Labath <pavelo@centrum.sk>
Sometimes wlan related TEXT causes segment fault, and backtrace shows it's strtok in
iw_get_stats.
I read the code of wireless_tools, which says 'strtok not thread safe, not used in WE-12 and
later' for iw_get_stats. But it need to first check if has_range and then we_version_compiled.
In conky/src/linux.cc, iw_get_stats is called before iw_get_range_info, hence has_range is always
0 in iw_get_stats and strtok is used. I simply move iw_get_range_info before iw_get_stats and no
segfault up to now.
patch by ruikai
