Re: [E-devel] E SVN: mej IN trunk/eterm: Eterm/src Eterm/utils libast/src libast/test spite
On Tue, Aug 24, 2010 at 1:38 AM, David Seikel onef...@gmail.com wrote:
Yes, I'm fully aware that far to often I just do if (pointer) or if
(!pointer). I don't see if (!!pointer) as being any more readable
or correct than if (pointer), while grudgingly admitting that if
(NULL != pointer) is likely more correct. It says what is meant, and
And you could check the script actually changed if (a != NULL) to if (a).
Suppose you have a function with an Eina_Bool parameter. It's wrong to to do
1) func(3);
2) char *a = bla; func(a)
3) Eina_Bool func2() { int a = 3; return a; }
You have an Eina_Bool, that should be true or false. !! will convert
that pointer to EINA_TRUE if it's different than 0 and to EINA_FALSE
if it's 0.
Btw, googling for C programming double negation does return some
meaningful results.
Lucas De Marchi
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: mej IN trunk/eterm: Eterm/src Eterm/utils libast/src libast/test spite
On Mon, Aug 23, 2010 at 3:28 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: On Mon, Aug 23, 2010 at 2:55 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Revert coccinelle changes. Using !! instead of != NULL results in significantly and unacceptably less readable code, and I refuse to accept those changes. Unfortunately, since they were all done at once, I have to revert the whole thing. Oh well. :( Did you revert the whole thing? Why do you have to do so? At least for EFL, it should be like this as agreed on mailing list / irc Ahn... you are talking about the other changes. I can disable those and apply for you if you want. But it's well automated/understandable by SCRIPTS/coccinelle/spatchall.sh, if you want to apply by yourself. Lucas De Marchi -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: mej IN trunk/eterm: Eterm/src Eterm/utils libast/src libast/test spite
On Mon, 23 Aug 2010 15:28 -0300, Lucas De Marchi wrote : On Mon, Aug 23, 2010 at 2:55 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Revert coccinelle changes. Using !! instead of != NULL results in significantly and unacceptably less readable code, and I refuse to accept those changes. Unfortunately, since they were all done at once, I have to revert the whole thing. Oh well. :( Did you revert the whole thing? Why do you have to do so? At least for EFL, it should be like this as agreed on mailing list / irc The particular change Michael is unhappy with is != NULL = !!, and he did express his disagreement about it (and so did I, FWIW). That being said, I'm not going to fight over it if the general opinion is that it's fine. Cheers, -- Albin Tonnerre -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: mej IN trunk/eterm: Eterm/src Eterm/utils libast/src libast/test spite
On Tuesday, 24 August 2010, at 13:32:06 (+1000), David Seikel wrote: I'm going to agree that !! is unreadable. Um, does that mean negate the negation, hence do nothing, or is their an obscure !! operator I have somehow missed in my decades of C programming? Don't think I have ever seen it before, so would not count is as well known C practice. No doubt for the same reason that double negatives are discouraged in English. Not being equal to NULL says something, negating the negation is just noise. Double negation insures that whatever the compiler's default boolean value is (sometimes 1, sometimes -1, but theoretically could be whatever non-zero value it wants, so long as it's consistent) gets assigned/tested. The double negation insures that any true value gets negated to false then negated again to the compiler's inate true value. Unfortunately raster thinks anyone who prefers the original notation over !! simply doesn't know the above and thus needs to learn something. So we're all just morons who don't know anything, and raster is always right. Again. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ m...@kainx.org Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- Come stand a little bit closer. Breathe in and get a bit higher. You'll never know what hit you when I get to you. -- Savage Garden, I Want You -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: mej IN trunk/eterm: Eterm/src Eterm/utils libast/src libast/test spite
On Mon, 23 Aug 2010 20:59:54 -0700 Michael Jennings m...@kainx.org wrote: On Tuesday, 24 August 2010, at 13:32:06 (+1000), David Seikel wrote: I'm going to agree that !! is unreadable. Um, does that mean negate the negation, hence do nothing, or is their an obscure !! operator I have somehow missed in my decades of C programming? Don't think I have ever seen it before, so would not count is as well known C practice. No doubt for the same reason that double negatives are discouraged in English. Not being equal to NULL says something, negating the negation is just noise. Double negation insures that whatever the compiler's default boolean value is (sometimes 1, sometimes -1, but theoretically could be whatever non-zero value it wants, so long as it's consistent) gets assigned/tested. The double negation insures that any true value gets negated to false then negated again to the compiler's inate true value. Um, so it's just a cast to boolean really? Though still it's not the same thing as checking for equality with NULL. In the case of pointers, it's the equivalence or lack of equivalence with NULL that is the important thing. NULL pointers meaning this pointer does not currently point to anything. We don't really care if the pointer, when cast to a proper boolean value, is true or false, that is completely unrelated to it's identity as a pointer. It may actually work, but it's not what we are interested in. We want to know if the pointer points to something. In C, that means if it is NULL. I understand that on some obscure platforms that we likely don't care about, NULL is not zero, so !! might not actually be portable for pointer NULL testing. Yes, I'm fully aware that far to often I just do if (pointer) or if (!pointer). I don't see if (!!pointer) as being any more readable or correct than if (pointer), while grudgingly admitting that if (NULL != pointer) is likely more correct. It says what is meant, and the boolean operator produces a boolean result to be used by the boolean statement, no odd casting mishaps possible on obscure platforms. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: mej IN trunk/eterm: Eterm/src Eterm/utils libast/src libast/test spite
On Tuesday, 24 August 2010, at 14:38:17 (+1000), David Seikel wrote: Um, so it's just a cast to boolean really? Though still it's not the same thing as checking for equality with NULL. In the case of pointers, it's the equivalence or lack of equivalence with NULL that is the important thing. NULL pointers meaning this pointer does not currently point to anything. We don't really care if the pointer, when cast to a proper boolean value, is true or false, that is completely unrelated to it's identity as a pointer. It may actually work, but it's not what we are interested in. We want to know if the pointer points to something. In C, that means if it is NULL. This is specifically for cases where a boolean value (i.e., Eina_Bool, which is by definition either 0 or !0) is either being assigned to a variable or passed to a function. if (ptr) is still used, but boolvar = (a != NULL) becomes boolvar = !!a. I understand that on some obscure platforms that we likely don't care about, NULL is not zero, so !! might not actually be portable for pointer NULL testing. It's not the NULL value that matters here, but rather the true value. !0 may or may not be 1 (~0 is also used). Yes, I'm fully aware that far to often I just do if (pointer) or if (!pointer). I don't see if (!!pointer) as being any more readable or correct than if (pointer), while grudgingly admitting that if (NULL != pointer) is likely more correct. It says what is meant, and the boolean operator produces a boolean result to be used by the boolean statement, no odd casting mishaps possible on obscure platforms. I find if (ptr) and if (!ptr) perfectly readable because my brain recognizes if pointer and if not pointer semantics. BTW, after further discussions with raster, it turns out we actually agree for the most part on the usage of !!. It just happens that the coccinelle script misinterpreted some of my stuff and was too overzealous. I don't mind b = !!a but I do mind ASSERT(!!a) which coccinelle mistakes for a function. I think this was all one big misunderstanding. :( Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ m...@kainx.org Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- Feel your breath on my shoulder, and I know we couldn't get any closer. I don't want to act tough; I just want to fall in love as we move into the night.-- Peter Cetera and Crystal Bernard, (I Wanna Take) Forever Tonight -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
