Summary:
the following commits did not correctly add super calls to the destructor,
resulting in a massive number of build errors as well as some unit test failures
ref e51699afbc
ref 38be95b0b6
Reviewers: raster, lauromoura
Reviewed By: lauromoura
Subscribers: lauromoura, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9902
Coverity reports that we leak the return from _escape(command) here,
so since we have to free the return from _escape, place it in it's own
variable that we can call free() on after we are done with it.
Fixes CID1399105
@fix
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D8688
This patch fixes an issue detected by Coverity where
pd->string_command is dereferenced before a NULL check.
Fixes Coverity CID1399098
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D8311
Coverity reports a dereference before NULL check here. In the for
loop, we are NULL checking 'array', however it has already been
dereferenced before the 'for' loop in eina_array_new above. This patch
fixes the issue by NULL checking 'array' before we ever try to use it.
Fixes Coverity CID1399083
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D8307
Small patch to fix a resource leak. Variable 'command' goes out of
scope here which causes a leak.
Fixes Coverity CID1399085
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D8308
Small patch to remove logically dead code. Coverity reports that
execution cannot reach the expression 0U inside this for statement. At
this point in execution, 'array' cannot be NULL, so checking for its
existence is a logically dead check.
Fixes Coverity CID1399106
@fix
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D8306
first use consistent ownership (stringshare the strings) and then also
properly dup and pass them and not free null arrays and so on where
they are used
strings often enough are generated e.g. via "%s/%s" or "%i" or similar
etc. ... i have poitned to examples, so move to make all strings
consistently stringshared, fix a bug added to the efl thread code
where it accessed and freed array even tho array was consumed (but not
strings) in the set, and the code used free to consume not
stringshare_del. fix other code and tests to match
EXCTLY the kind of bugs and mistakes with this kind of design that i
said would happen more often just happened...
This reverts commit a57c7f7510.
I pretty much hate to just revert your revert, but you failed to read my
replies, and failed to understand what i was talking about.
And YES we talked at fosdem about the platform issue, and do you
remember my answer, that back in time this might be the case, today is
different freebsd suppoerts setenv, and for windows we have a setenv
implementation in evil. And yes, vtorri also created a issue how bad and
evil this commit is, however, i still fail to see the issue since setenv
unsetenv and clearenv usages are taken as needed. (T7693)
The ownership question is answered in
https://phab.enlightenment.org/D7516#137367.
Can we please get into a state of technical discussions, and not *oh
shit, i am going to revert this* this has been in review for a long
time, a lots of people have tested it, we discussed things on it, and
there was 3 weeks of no reply from you.
The issues that exist will be dealed with. Feel free to create tasks if
you want :)
Revert "ecore: get rid of commands in efl_task."
This reverts commit 616381e9cf.
Revert "ecore: here comes a command line object"
This reverts commit 48e5684b3c.
1. this is broken:
EOLIAN static const char*
_efl_core_command_line_command_get(const Eo *obj EINA_UNUSED, Efl_Core_Command_Line_Data *pd)
{
return eina_strdup(pd->string_command);
}
it returns a const char * BUT it duplicates it on return. no. a big
fat honking NO. return a char * or don't duplicate. pick.
2. _efl_core_command_line_command_array_set() is broken by design. it
accepts an array of strings, but the strings are owned by the caller
who creates the array (requiring they free them up themselves after
this call) but the array becomes owned by the callee. the code here frees the
incoming array but doesn't care about the string content of it. it's
leak heaven waiting to happen (or bugs when someone wants to access
the array they create to walk it to free the strings they put into it
after it is set).
i brought this up and it was dismissed. now exactly he issue i brought
up is there with mixed ownership and the added complexity as well as
transfer of some ownership but not others.
go back and think about this so it isn't broken by design.
the mixin for now can carry a command, which can be setted as an string.
The string is then parsed again, this is done in order to make sure that
everything that needs escaping really is escaped or parsed correctly.
Differential Revision: https://phab.enlightenment.org/D7516
Mike Blumenkrantz
Carsten Haitzler
Christopher Michael
Marcel Hollerbach