The problem is in this statement:
assert((entry == IE_NULL) || IE_BITS_TYPE(entry-ie_bits));
The macro assert() checks for a negation of this expression. Negation of an
OR expression is an AND expression. In order to evaluate an AND expression,
compiler needs to check both conditions. So it
On Wed, 18 Dec 2013 09:17:47 +0100
Marin Ramesa m...@hi.t-com.hr wrote:
...
Negation of an
OR expression is an AND expression.
...
Maybe I did't get you correctly, but isn't !(a || b) == !a !b ?
And evaluation of the second condition doesn't happen when entry = IE_NULL
--
Regards,
On 18.12.2013 10:20:21, Anatoly A. Kazantsev wrote:
On Wed, 18 Dec 2013 09:17:47 +0100
Marin Ramesa m...@hi.t-com.hr wrote:
...
Negation of an
OR expression is an AND expression.
...
Maybe I did't get you correctly, but isn't !(a || b) == !a !b ?
Yes.
And evaluation of the
On Wed, Dec 18, 2013 at 10:37:03AM +0100, Marin Ramesa wrote:
Compiler needs to check both !a and !b. In order to evaluate !b it must
evaluate b. So when the code path is that when entry is a null pointer,
the evaluation of b results in a dereference of a null pointer.
No, that's wrong. The
On Wed, Dec 18, 2013 at 10:46:40AM +0100, Richard Braun wrote:
On Wed, Dec 18, 2013 at 10:37:03AM +0100, Marin Ramesa wrote:
Compiler needs to check both !a and !b. In order to evaluate !b it must
evaluate b. So when the code path is that when entry is a null pointer,
the evaluation of b
On 18.12.2013 10:46:40, Richard Braun wrote:
On Wed, Dec 18, 2013 at 10:37:03AM +0100, Marin Ramesa wrote:
Compiler needs to check both !a and !b. In order to evaluate !b it
must evaluate b. So when the code path is that when entry is a null
pointer, the evaluation of b results in a
On 18.12.2013 10:55:47, Marin Ramesa wrote:
in order to return TRUE
Sorry, I meant to say in order to return FALSE.
On Wed, Dec 18, 2013 at 10:55:47AM +0100, Marin Ramesa wrote:
On 18.12.2013 10:46:40, Richard Braun wrote:
No, that's wrong. The and || operators are guaranteed to be
evaluated left-to-right, and yield if the first operand compares
equal to 0. And that's exactly why this check against
On 18.12.2013 11:11:10, Richard Braun wrote:
The expression is ((a == NULL) || a-something), and I agree it is
equivalent to !((a != NULL) !a-something). And again, both the
and || operators are guaranteed to be evaluated left-to-right and
*yield* without evaluating the second operand if the
Marin Ramesa m...@hi.t-com.hr writes:
On 18.12.2013 10:46:40, Richard Braun wrote:
[...]
No, that's wrong. The and || operators are guaranteed to be
evaluated left-to-right, and yield if the first operand compares
equal to 0. And that's exactly why this check against NULL is done
On Wed, Dec 18, 2013 at 11:25:36AM +0100, Marin Ramesa wrote:
Yes, vou're right. I got confused. But then something else is happening
here. When I write the assertion this way:
assert((entry == IE_NULL) || ((entry != IE_NULL) ? IE_BITS_TYPE
(entry-ie_bits) : TRUE));
GCC stops complaing
On 18.12.2013 11:34:03, Richard Braun wrote:
On Wed, Dec 18, 2013 at 11:25:36AM +0100, Marin Ramesa wrote:
Yes, vou're right. I got confused. But then something else is
happening here. When I write the assertion this way:
assert((entry == IE_NULL) || ((entry != IE_NULL) ? IE_BITS_TYPE
On Wed, Dec 18, 2013 at 11:40:09AM +0100, Marin Ramesa wrote:
On 18.12.2013 11:34:03, Richard Braun wrote:
I don't get this warning, can you tell us how you configure GNU
Mach ?
--enable-kdb --prefix=
But the warning is turned off by:
ipc_port_t notify_port = 0;
in
On 18.12.2013 12:00:49, Richard Braun wrote:
On Wed, Dec 18, 2013 at 11:40:09AM +0100, Marin Ramesa wrote:
On 18.12.2013 11:34:03, Richard Braun wrote:
I don't get this warning, can you tell us how you configure GNU
Mach ?
--enable-kdb --prefix=
But the warning is turned off
14 matches
Mail list logo
