there is not yet a CID for this, but we should probebly not do that.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D11731
this is a obscure check, if this was ever reached, then it would simply
crash, because one pointer will be NULL, but strcmp will be called on
it.
CID 1419854
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11722
checkinf for it beeing NULL means that we would have to equip every
usage of unit1 with a check, but that is useless.
CID 1419859
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11721
ii might be NULL so we should ensure it is not NULL to call item_select
CID 1419865
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11720
these if clause where a bit bottom up, and the xor operation here seemed
totally wrong, with this code we are simply displaying both entiteis of
the two structs when they are there. *or* we are replacing it with the
fallback.
CID1419875
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11719
Summary:
The Exactness tool needed usage instructions... and quite some more
fixes. There was copypasta all around.
Depends on D11634
Test Plan: Build and Enjoy
Reviewers: bu5hm4n, stefan_schmidt
Reviewed By: stefan_schmidt
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11637
We do not want to have EAPI from exactness exposed at this point without
any real user. I know of no application using the exactness library.
If we come to that point we can move things back into a lib, but for now
having the code shared between the various executables is all we need.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11545
From now on we will only go with the new .exu format. All tests have
been converted two and a half years ago already. If there still is a
need for this in some corner cases the external exactness application
still has support for this.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11537
First step to do some re-factoring of the exactness binaries. We will
share common parts from the different binaries in common.{c,h} to reduce
the code duplication. The start makes _printf() used in various places.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11456
Coverity pointed these out as we deferences after null check.
Looking into it showed these use of a bitwise operator on vars where it
does not make any sense (to me). They look like wrongly done NULL
checks. Switchign them over to a logical OR operator.
CID: 1419876, 1419869, 1419868, 1419862, 1419854, 1419849
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11432
If dt equals EX_FONTS_DIR we would have returned already.
CID: 1419879
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11430
We need to amke sure we free this images before we return.
CID: 1419848
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11413
Before we leave the scope here this needs to get free'd up or it will
leak.
CID: 1419877
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11408
If we hit this error path we need to release the allocated buffer.
CID: 1419878
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11407
Just a few that I spotted when looking over the code.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11290
The init/shutdown handling for efl libraries was a bit sloppy and
unbalanced in the exactness binaries. Switching over to use
ecore_eas_init/shutdown here instead of doing all libs individually.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11289
Either commented out, blank lines or no needed includes.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11288
This has been in place during development and not updated for recent
changes and merge into efl master.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11287
Exactness has been developed in a separate git repo for many years. This
finally moves it over into efl. Having it in tree allows us for easier
testing with our current main target elementary_test and integration
into our CI system (patches for this are work in progress already).
We are only importing the lib and binary for test execution, not the
full set of test data. This is would be over 500MB and thus it will stay
in a different repo and only made available during the actual testing.
[The original patch was made by Daniel Zaoui. Over the course of review
and testing it got extended with build fixes for API changes and mingw
compilation support from Stefan Schmidt and Michael Blumenkrantz]
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11285