Summary:
when defined, BUILD_EDJE_FP causes some of these struct members to not
be floating types and additionally defines special macros to be used
for comparisons to handle this case
Depends on D11786
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11787
that is a unsigned int, if its 0 the timer is called as fast as
possible. Not doing that breaks exactness.
@fix
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11774
This has been unused since the move to a preloaded lib and now makes
trouble durign compilation on Fedora32.
@fix
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11767
If the given events list is NULL the data pointer would be as well. Make
sure we check for NULL here before accessing.
CID: 1419843
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11754
Instead of doing our own parsing here we should use ecore_file_dir_get()
which uses dirname() already to solve this.
CID: 1422196
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11727
These to code lines should be in one block and not one exectued without
the if.
CID: 1422198
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11726
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
In an error case the fd could be negative here and we should check
before feeding it into fdopen(). This is the same patch we used in
recorder.c
CID: 1422194
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11728
In an error case the fd could be negative here and we should check
before feeding it into fdopen().
CID: 1422197
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11725
We never checked how many bytes had been written. Check on return and
propagate error upwards to caller.
CID: 1419856
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11724
We no longer support the old .rec format and we can always expect the
file to be exu. Coverity found this block to be always true so the else
part could not be reached.
CID: 1421996
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11723
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
We get fonts_dir from a getenv() without and length check. Make sure
that we stay in the given buffer size when stitching the file path
together.
CID: 1422195
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11718
This has been around for prg handling before we switched to preload. No
need for it anymore. Found when looking for a Coverity issue, which also
got fixed now by luck. :-)
CID: 1421994
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11713
Three renames are applied here:
Efl.Text.Cursor -> Efl.Text_Cursor.Object (class)
Efl.Text.Cursor_Type -> Efl.Text_Cursor.Type (enum)
Efl.Text.Cursor_Move_Type -> Efl.Text_Cursor.Move_Type (enum)
Nothing changes for the enums on the C side. For the class... Well,
the method names are a bit more verbose now.
These renames are required to avoid clashing with the Efl.Text interface.
This did not cause trouble to C# because interfaces are prefixed with "I",
but it did cause trouble to Eolian when the EO files were installed and
somebody tried to use them.
Ref T8648
Differential Revision: https://phab.enlightenment.org/D11663
This brings into the docs hundreds of methods!
due to the ingroup->defgroup mistake, they were out of any scope
and therefore they were silently ignored by doxygen.
Also, document lots of missing "obj" parameters. Not strictly necessary, but
this further reduces the number of doxygen warnings.
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
there came up a issue, where a excatness spawned processes were bringing
up a efreetd instance, when the efreetd instance turned off itself, the
files for exactness were written again, which is wrong. This ensures
that forked instances do not take any actions.
Differential Revision: https://phab.enlightenment.org/D11634
if _src_unit is NULL, the write here would delete the actions, with this
commit we ensure that this is printing an error.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11627
before a few commits, we had the situation that errors were overseen
because the log was simply so big, that errors did not get shown
properly.
With this commit, exactness will simply abort if there is a real issue
in the code.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11624
we should not error when mkdir returns < 0. EEXIST should not result in
the return here.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11618
there is no need to do that, more than that. This is super dangerous,
the display and connection ptr of x are passed from ecore_evas to evas,
if you delete evas before ecore_evas, the later ecore_evas deletion will
destroy the x connection which calls some functions in evas, which is
already freed, which leads to a crash.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11617
this is just a little python script, so you can lunch exactness_play
without the need of handdefining LD_PRELOAD
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11616
this can now be loaded as LD_PRELOAD library
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11615
this refactors everything that is not argc argv related out of the main
method. For later usage
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11614
this seems to be made for compiling binaries before testing. That sounds
like a good idea, however, implementing a full buildtool in exactness is
a bit hard. Hence, using meson for that would be better.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11613
this is just a little python script, so you can lunch exactness_record
without the need of handdefining LD_PRELOAD
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11611
this is now not a binary anymore, that dlopen's a binary, it is now a
library, that can be loaded using LD_PRELOAD. EXACTNESS_DEST is used for
the path of the .exu file. EXACTNESS_FONTS_DIR is used to get the fonts
directory
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11610
all calls taht are not related to env var checking, are moved out of the
main method. That is in preparation for later refactorings.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11623
_test_name was not used globally, so lets move it to the used scope.
Verbose is not used at all either.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11609
this commit removes the code that was changing argv values, and replaces
it with a new array. Which is absolutly fine, as the argv / argc values
are never accessed later on. Only the copies that have been passed to
efl_main or elm_main.
This resolves several issues:
1. the for loop is useless, every single array element that gets
initialized with it, is some offset from argv[0] this may also crash
when argv[i] - argv[opt_args] is bigger strlen argv[0].
2. The memcpy here is super dangerous, the dest array is not garanteed
to have the same size as argv[0], this only works if the client
application name is shorter than the name "exactness_recorder"
3. The memset here is absolutly wrong. There is again no garantee that
the array has the expected size behind that, this was constantly
overwriting the segment after the place where argv was stored, which
was lukely enough on fedora always the environs, which deleted the
couple first segments. (This was not causing any fuzz, since they
have been sudo related env vars on the docker image). However, on
arch this just crashed right away. On Ubuntu this overwrote DISPLAY,
which resulted in the unability to launch the app.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11600
we have initialized it, we should shutdown it.
This was we are not getting random vtable allocation leak reports in the
asan job anymore.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Chris Michael <cp.michael@samsung.com>
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11572
Use a full eina_log domain here for each executable. No need to have a
own half baked ex_printf version here for such things.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11558