fixes CID 1361219
if you had an env var a few gb in size or we had stuff in the last bit
of memory address space this might be an issue, but that won't happen.
@fix
fixes CID 1361220
in theory yes end minus start could be insanely huge or end be very
high in memory thus causing an overflow. this would have to be in the
last few bytes of memory space, so it never going to happen. and the
input from the env var has to be sane anyway as its user controlled.
@fix
This reverts commit 8a988717e1.
It seems we can't actually inherit from class more than once and neither eo
nor eolian will complain about it. You will just get random weird behavior.
This patch should come back once we have made an interface of edje.
so ecore-con already cleared the slaves list on shutdown but an
ecore_thread may stillbe active and thus removing from a NULL slaves
list wont work, so skip if slaves is NULL.
@fix
the way eina does sempahores, they can NEVER be sensibly shared
cross-process portably. so enabling sharing is a pointless idea. in
fact some os's like openbsd check if the sempahore addres is in a
sharable mem region and deny init if it is not. on osx you dont use
shared memory but a sempahore name you share instead... and this is
not exposed thus it can't be shared either. if we did process sharable
semaphores we'd make shm segments and/or name them in a sharable way
were you can share the idenitifer of the shm segment and/or the offset
address or name from osx. but we don't, so making them
process-private is the right thing. sharable sempahores will need a
whole new api.
this also fixes osx naming to make the name pretty unguessable/private
and opened exclusive (or it fails) by using pid, sem counter, and 4
random numbers. it's not a security mechanism as the create will fail
if there is a clash. chances are low. we unlink before anyway. good
enough for osx for now.
@fix
so thats a common local port to use for other things... 8080 - don't
use it, so use 12346 much like 12345 is for the other tests. far less
likely to clash. fix up tests to work better.
There is a line to check select_mode in _item_select function.
The item selected(clicked) callback is called when the select_mode is ELM_OBJECT_SELECT_MODE_NONE.
The checking select_mode should be handled at one place.
fill in the padding of mesages (10 bytes) with something so valgrinds
can be happy and use vlatiole for msgs count as the msgs num should
have been incremented already before the msg sned is done and main
thread/loop gets the msg
this should make ecore_imf testable with empty env vars also meaning
no env var and the make check test will now ensuree this is set to
exactly test this.
This is to avoid ERR messages such as "object is not an image!"
that can happen when a legacy image function is called on an
eo image (proxy, 3d, ...) object.
Note: This does not fix any known issue, but it's probably a safer
solution.
This removes some useless code in various places, where the
switch from eo_do() to standard function call was not properly
refactored.
This changes:
type ret = 0;
ret = my_eo_function();
return ret;
To:
return my_eo_function();
In elm_image, efl_file_get() was called on a legacy Evas Image
object, which generated an ERR message. This was way too much
noise for something that actually works.
It's best not to call efl_file_get/set API on a legacy
object, but it can be convenient for smooth code transitions
from legacy to pure eo.
Also, add safety to those APIs.
Test case: elm_test genlist dnd, start dragging anything.
this fixes errors like:
ERR<4864>:eet lib/eet/eet_lib.c:645 eet_shutdown() File '/home/osauser/.cache/efreet/icons___efreet_fallback_localhost.localdomain.eet' is still open 1 times !
@fix
so we didnt set everything to null after being freed and object sae
freed after some data. do the data frees after objects are deleted so
callbacks cant access null data anyway. this makes this edje shutdown
far more robust and safe. massive improvement in stability i hope.
We found a some build break problem due to a build system.
In efl configuration, our efl configure enables neon if it's available,
but neon gonna partially turned off on evas compilation if the build system
has a non neon CFLAG option (ie, mfpu=vfpv..). In the end, neon is partially enabled
and it turns out a build break.
It's non-sense but we can't allow this breakage.
There is no way to ignore build system option nor override our neon option perfectly,
so, Let efl package ruled by build system overall.
as per bug. requiring by DEFAULT 2 video back ends is rather
rediculous. pick one and the others are optional. you could argue xine
now is barely worth it, but it's stable and works and has proven to be
not any real pain.
gst1 is a more optimal and far more complete/featured backend that the
vlc generic one anyway. vlc generic has the bonus of out-of-process,
but gst1 is pretty stable (unlike the 0.1 backend), so let's not make
peolpe install 2 video backends (or possibly 3 or more) just to build
efl out of the box.
this fixes T4284
Carsten Haitzler
Stephen Houston
Stefan Schmidt
Cedric Bail
Davide Andreoli
Shinwoo Kim
Jean-Philippe Andre
Daniel Kolesa
Marcel Hollerbach
Daniel Hirt
Hermet Park
Subhransu Mohanty
Andy Williams