Apply badzero.cocci, badnull.coci and badnull2.cocci
This should convert all cases where there's a comparison to NULL to simpler
forms. This patch applies the following transformations:
code before patch ||code after patch
===============================================================
return a == NULL; return !a;
return a != NULL; return !!a;
func(a == NULL); func(!a);
func(a != NULL); func(!!a);
b = a == NULL; b = !a;
b = a != NULL; b = !!a;
b = a == NULL ? c : d; b = !a ? c : d;
b = a != NULL ? c : d; b = a ? c : d;
other cases:
a == NULL !a
a != NULL a
SVN revision: 51487
* eina_str_split() now does the minimum number of passes and
allocations. The first pass figures out the string size (strlen())
and number of delimiters, so we can allocate the exact number of
elements in array. The second repeats the loop copying elements to
string and also setting them to the result array.
* eina_str_split_full() is a variation of eina_str_split() that
returns also the number of elements in array, in the case you need
to pre-allocate another array to copy.
* eina_strlen_bounded() is introduced to limit strlen() results, this
is used in has_prefix and has_suffix, but possibly other use cases
where string must be of a maximum size as we don't do useless
iterations;
SVN revision: 46547
as we are on the modules context not the array.
All the referenced projects are changed too. Remember that the list_free()
already calls the unload() on each module so no need to call list_unload()
SVN revision: 44978
This new iterator receives a rectangle as argument and tile_w X tile_h sized
tile, and slices the rectangle iterating over it on each iteration.
SVN revision: 42427
Being able to indivually initialize individual modules was initially
"good", but at end it's putting complexities on users that would try
to "optimize" by doing just what they used, but in the end most people
would get them wrong, users would have to do lots of code and etc. At
the end it does not worth.
Most module init just register handful errors and log domains, so are
cheap. The exception is mempool users, that would dlopen() stuff, but
people that are concerned (embedded) can just compile those statically
in eina.
Since at the end any real application would use most of modules, we
actually end saving lots of function calls that would do nothing other
than increment a global counter.
I also did the init/shutdown use an array, making it easier to
maintain. The inital dependencies were analysed by a script I wrote, I
hope it's all right.
Please fix any breakages you find!
SVN revision: 42300
Sparse Matrix was implemented and tested by Rafael Antognolli and
myself in order to implement optimized large sparse matrix walk in
some products, one of them WebKit-EFL optimizations.
We have done extensive tests, with good code coverage. Similar to
lists/inlists, we keep pointer to last known element and similar to
iterators we keep reference to last accessed row and cell inside
rows. This allows fast sequential access (for i... for j... m[i,j]),
that is our most common usage case.
Rows are kept in a list, with cells inside that row as another
list. It's not similar to most book implementations where cells keep
reference to their sibling cells in other rows as well, we opted to
not do that to save some pointers and make algorithms simpler, still
do great for our use case.
This code was developed on behalf of our client, that wants to remain
unnamed so far. Thanks client ;-)
SVN revision: 42243
* eina_error might be kept for error messages and codes, but it's logging API
will be deprecated. For now, it's been kept for not breaking others code and
for a smoother transition.
* Added test for new logging API, also demonstrates usage.
SVN revision: 41960
The current implementation choose to move the node allocation outside of eina
control like eina_inlist. They currently have the same memory footprint as
eina_inlist and the implementation of insertion and lookup are iterative
making it quite fast. This should make them a good competitor of eina_inlist
for eina_hash and eina_stringshare.
SVN revision: 35689
received. It's a little huge right now, but work quite nicely.
It support "static" module, version, recursive lookup and should be able to
replace the module/plugins support in evas and ecore.
SVN revision: 35534