otherwise we would just reuse that struct. This results in
freeing/writing/reading the memory twice.
This error message should give the dev a tip on what went wrong, instead
of leaving cryptic valgrind messages and crashes.
This fixes the sysinfo desktop gadget in enlightenment.
ref T5173
when the position of the container is changed the children should also be
repositioned, so setting the changed flag.
The visual effect where you saw that was in luncher where items of the
bar did not get fully up.
this struct is not actually used other than in this func ptr decl and
it's warning-land for gcc, so .. make it void * and do things like
pretty much all other gl extn func ptrs... be very generic
this struct is not actually used other than in this func ptr decl and
it's warning-land for gcc, so .. make it void * and do things like
pretty much all other gl extn func ptrs... be very generic
it's a warning one way or another so reduce noise with a harmless case
as passing in a pit ro a 32bit type is more restrictive than the ptr
it accepts (an 8bit type)
yes - we compare a difference between 2 ptrs and an index which is a
uint. the safe thing here is to promote the unit to the ptrdiff_t
type. reality is we cant have more than 2^32 cb's on an object
anyway... so this should be ok.
every time i build efl i see all these warnigns spew by about elm_code
and possibly uninited vars being used. yes - they're filled in via ptr
ref bya func but gcc definitely seems to think they MIGHT not be
filled in in some cases... and either way tyhe cost of setting to 0 is
minimal and less noise is better so we see real warnings more
easily... :)
Not sure _ecore_fd_valid() is all that useful anymore, as the
commit that introduced it said it would be removed "before release"
a long time ago - it's a debug assist that probably doesn't need
to be in release builds.
(I'm counting syscalls on rpi3 - still, calling this an optimization
seems like a bit of a stretch.)
We had to do some weird special case stuff when binding wl_compositor
because we implemented damage buffer before depending on a wayland
release that provided it.
Now our wayland dep is newer than damage buffer, so the test can be
more conventional.
Should have no functional change.
since these are only local path resolves, the do and wait are
technically not needed. also remove any other tmp strings
and use the vpath string resolving feature to avoid
printfs/strjoins/cats etc. etc. as well.
also remember to remove old name string from evas shm code - it worked
for me. i guess i was lucky and it happened to be NULL thus free was
fine.
When the XCB support was removed end of last year the .gitignore file left
behind. It was the only file still sitting in the src/utils tree so git removes
the whoile subtree now.
This reverts commit 2037474dc0.
This causes the wayland_shm engine to seg fault immediately at
startup when attempting to create shm buffers.
Please make sure when committing changes to the wayland_shm engine to
test on intel, exynos, and at least one platform without dmabuf
capabilities - or using the EVAS_WAYLAND_SHM_DISABLE_DMABUF env var
to disable dmabuf on intel or exynos.
Anyone without the time or hardware to fully test changes to wayland_shm
can submit a patch to phabricator and assign it to me so I can fully
test it before landing.
since these are only local path resolves, the do and wait are
technically not needed. also remove any other tmp strings and use the
vpath string resolving feature to avoid printfs/strjoins/cats etc.
etc. as well.
this fixes a bug where elm_cofnig would firstly use
~/.config/elementary which isnt what we have used before and so would
break older config. also it'd create junk if it was setuid. fix this.
@fix
this allows only /dev/fb[0-0] or /dev/fb/something where somthing does
not begin with a . - thus no way to break out of the fb subdir... so
it should be ok... this keeps setuid safety and allows this env var to
work now as intended in this situation.
if a setuid app needs efreet - it will not be able to contact the
users' efreetd and thus may spawn it's own... and thus we cant have
this now spawned efreetd using env vars inherited from the
unpriveleged etc. user, so ignore them.
this should make the wayland shm engine safe to use from setuid
processes. it shouldnt depend on getenv of specific file paths if
setuid. vpatrh takes care of this in one central place
Marcel Hollerbach
Carsten Haitzler
Cedric BAIL
Mike Blumenkrantz
Andy Williams
Derek Foreman
Daniel Kolesa
Stefan Schmidt
Romain Naour
Felipe Magno de Almeida