arrange.c: Highly unlikely, maybe impossible situations
backgrounds.c: False positive (I think)
dialog.c: Fix memleak/segv on realloc failure
focus.c: False positive
ewin should never be NULL with FOCUS_EWIN_NEW
main.c: False positive
eoptarg will always be set if argument requires option
menus.c: Fix memleak on malloc failure
session.c: Fix dead assignment
stacking.c: False positive
Changed code is nicer though
pager.c: False positive
ewin would never be NULL if hiwin was NULL
But rearrange for clarity anyway
ecompmgr.c: Avoid bogus issues
It seems that sometimes there are rendering glitches when having a tiled
backround with 0 offsets and tile size less than screen size.
In this case the desktop pixmap would be smaller than the screen size and
we rely on the repeat picture attribute in the desktop picture to get it
tiled over the entire desktop window when compositing.
However, it seems that sometimes(?) the desktop window is not properly
repainted outside the top left tile.
To fix this we now always use a full-sized background pixmap when
compositing is enabled.
I think this is an X-server bug but I haven't been able to produce a
test case demonstrating the problem.
Split into separate functions so we don't have to check on val all over
to figure out if it is one or the other.
This also avoids that the apply stuff may be done twice on exit a couple
of places.
Suggested by Daniel Manjarres.
In order to avoid compatibility issues with older e16 versions
the backgrounds file is renamed from e_config-<something>.backgrounds to
e_config-<something>.bg.
SVN revision: 59082
Make the background images (also used in background selection menu)
screen size/12, which normally will be somewhat larger than the old 64x48.
Based on patches by Daniel Manjarres.
SVN revision: 59080
The offending projects were:
E16/e/src/backgrounds.c | 10 ++++------
PROTO/eon/src/lib/layout/eon_stack.c | 4 +---
ecore/src/lib/ecore_win32/ecore_win32.c | 3 +--
ecore/src/lib/ecore_wince/ecore_wince.c | 3 +--
edje/src/lib/edje_edit.c | 3 +--
evas/src/lib/cache/evas_cache_image.c | 2 +-
exalt/src/lib/libexalt_private.c | 2 +-
This patch assumes code in these places were insane and the fix is to remove
one condition check. Most likely this is not true, but there's no automatic fix
for that.
Looking at the patch, it seems that some places should use "x" and "y" vars but
used just one of them and therefore they were caught by coccinelle.
SVN revision: 51666
Apply badzero.cocci, badnull.coci and badnull2.cocci
This should convert all cases where there's a comparison to NULL to simpler
forms. This patch applies the following transformations:
code before patch ||code after patch
===============================================================
return a == NULL; return !a;
return a != NULL; return !!a;
func(a == NULL); func(!a);
func(a != NULL); func(!!a);
b = a == NULL; b = !a;
b = a != NULL; b = !!a;
b = a == NULL ? c : d; b = !a ? c : d;
b = a != NULL ? c : d; b = a ? c : d;
other cases:
a == NULL !a
a != NULL a
SVN revision: 51487
Since badzero.cocci depends on coccinelle knowledge about a variable being a pointer
and about a function returning a pointer, maybe there are false negatives.
SVN revision: 51092
The notnull.cocci script from Coccinelle finds places where you check if a
variable is NULL, but it's known not to be NULL. The check can be safely
removed. For example, this code would be caught by notnull:
if (!var) return;
if (var && var->fld) { ... }
It's needless to check again if var is not NULL because if it's in fact NULL,
it would have returned on the previous "if". This commit removes all the
trivial places where this pattern happens. Another patch will be generated for
the more complex cases.
SVN revision: 50241
Kim Woelders
Sebastian Dransfeld
Lucas De Marchi