On Fri, Feb 26, 2010 at 7:48 AM, Lucas De Marchi
<lucas.demar...@profusion.mobi> wrote:
> On Fri, Feb 26, 2010 at 2:56 AM, Enlightenment SVN
> <no-re...@enlightenment.org> wrote:
>> */
>> EAPI int
> Here we have int return value.
>
>> @@ -398,10 +398,10 @@
>> if (!ECORE_MAGIC_CHECK(p, ECORE_MAGIC_PIPE))
>> {
>> ECORE_MAGIC_FAIL(p, ECORE_MAGIC_PIPE, "ecore_pipe_write");
>> - return FALSE;
>> + return EINA_FALSE;
>
> And here we are returning Eina_Bool. Don't we have to change those
> cases? And there is a lot of cases like that.
yes, this is far from being a blocker, but fixing it in the whole EFL
would help understanding of function calls and returns...
find-and-replace could be easy, but problem is with pointer to
parameters, as this is much more likely to break things. Others will
just break ABI and recompile could fix it.
anyone willing to do it? Priority order would be most-user-visible ->
lesser-user-visible:
- edje
- evas
- ecore
AFAIR elementary is well done, but maybe review it?
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
