Can A Macro Do This?

[gamename]

Hi

Right now I do multiple asserts to verify multiple values:
assert(foo==X);
assert(foo==Y);
assert(foo==Z);

Is there any way to macro-ize this and do it in one call?
MYASRT(foo, (X||Y||Z));
... or maybe...
MYASRT(foo,OR,X ,Y,Z));

TIA,
-T

[Barry Schwarz]

On Mon, 03 Dec 2007 08:58:28 +0000, Philip Potter <pg*@doc.ic.ac. uk>
wrote:

>Barry Schwarz wrote:

>On Fri, 30 Nov 2007 12:54:04 +0000, Philip Potter <pg*@doc.ic.ac. uk>
wrote:

>>Barry Schwarz wrote:
On Wed, 28 Nov 2007 16:45:40 +0100, Björn Paetzel <ne**@kolrabi.d e>
wrote:

santosh schrieb:
>
>>How can foo be 3 different things at the same time as in the
>>origina l code???
>> >>>assert(foo== X);
>> >>>assert(foo== Y);
>> >>>assert(foo== Z);
>>>
>>That can't be right!
>Yes. The sequence of assert invocations as presented seem redundant. Of
>course some code could occur between the calls or the OP might have
>just presented this as an example to enquire about writing complex
>expression s with assert.
Maybe he wanted to something like this:
>
assert(foo= =X==Y==Z);
>
/* ;) */
Since == is not transitive in the same sense = is, it seems unlikely.
A relation R is transitive if a R b && b R c implies a R c for all
a,b,c. I believe this applies to == and it's even appropriate for =
because it isn't a relation.

Equality is transitive. The == operator is not.

Due to left to right associativity, the expression foo == X == Y == Z
is parsed as (((foo == X) == Y) == Z). The innermost expression must
evaluate to 0 or 1. If all four variables have the value 5, the
intuitive meaning of the expression should be TRUE but foo == X
evaluates to 1, 1 == Y evaluates to 0, and 0 == Z evaluates to 0 and
the expression is FALSE. Even if associativity were reversed, the
expression would still evaluate to FALSE.

You appear to have ignored my definition of transitivity.

If knowing that a == b && b == c means that you know for sure that a ==
c, then == is transitive. It has nothing to do with being able to use
the a == b == c syntax. As I said, I believe that == is transitive, but
I don't know the standard well enough to confirm this.

Well, if that were true this would produce three statements of
equality. It's a shame it won't compile. But, if you are not allowed
to compare them, how can you say they are equal?

#include <stdio.h>
int main(void){
int x[2];
int *a;
void *b;
int (*c)[2];
a = x;
b = x;
c = &x;
if (a == b) puts("a == b");
if (b == c) puts("b == c");
if (a == c)
puts("a == c");
else
puts("a != c");
getchar();
return 0;}
Remove del for email

[Philip Potter]

Barry Schwarz wrote:

On Mon, 03 Dec 2007 08:58:28 +0000, Philip Potter <pg*@doc.ic.ac. uk>
wrote:

>If knowing that a == b && b == c means that you know for sure that a ==
c, then == is transitive. It has nothing to do with being able to use
the a == b == c syntax. As I said, I believe that == is transitive, but
I don't know the standard well enough to confirm this.

Well, if that were true this would produce three statements of
equality. It's a shame it won't compile. But, if you are not allowed
to compare them, how can you say they are equal?

#include <stdio.h>
int main(void){
int x[2];
int *a;
void *b;
int (*c)[2];
a = x;
b = x;
c = &x;
if (a == b) puts("a == b");
if (b == c) puts("b == c");
if (a == c)
puts("a == c");
else
puts("a != c");
getchar();
return 0;}

It compiles on mine:

pgp@medusa-s2:~/tmp$ gcc -ansi -pedantic bs.c -obs
bs.c: In function `main':
bs.c:12: warning: comparison of distinct pointer types lacks a cast
pgp@medusa-s2:~/tmp$ ./bs
a == b
b == c
a == c
pgp@medusa-s2:~/tmp$

....although I accept that it's not guaranteed to compile everywhere.

I came up with a very similar example in <fj**********@a ioe.org>, which
I posted three days ago:

Hmm, for a = (int *) 0, b = 0, c = (float *) 0:

a == b && b == c, but a == c is a constraint violation. I think. So ==
is not transitive in the mathematical sense.

If we change the problem and limit ourselves to strictly-conforming
programs, is it possible to come up with expressions a, b, and c for
which a == b and b == c but a != c?

[Philip Potter]

ja*********@ver izon.net wrote:

Philip Potter wrote:

[snip]

#include <stdio.h>
#include <limits.h>
int main(void)
{
int a = -1;
unsigned b = UINT_MAX;
double c = b;

printf("a%c=b\n ", a==b ? '=' : '!');
printf("b%c=c\n ", b==c ? '=' : '!');
printf("a%c=c\n ", a==c ? '=' : '!');
return 0;
}

Output:
a==b
b==c
a!=c

Nice. Thanks a lot.

[Barry Schwarz]

On Thu, 06 Dec 2007 13:14:19 +0000, Philip Potter <pg*@doc.ic.ac. uk>
wrote:

>I came up with a very similar example in <fj**********@a ioe.org>, which
I posted three days ago:

Hmm, for a = (int *) 0, b = 0, c = (float *) 0:

a == b && b == c, but a == c is a constraint violation. I think. So ==
is not transitive in the mathematical sense.

This is the only point I was trying to make.

>

If we change the problem and limit ourselves to strictly-conforming
programs, is it possible to come up with expressions a, b, and c for
which a == b and b == c but a != c?

I expect there are floating point values, let's call one such value X,
for which
float a = X;
double b = X;
long double = X;
produces the situation in question due to the manner in which floating
point values are approximated. Unfortunately, I can't test it on my
system since long double and double have the same representation.
Remove del for email