Velocity Reviews > Can A Macro Do This?

# Can A Macro Do This?

Barry Schwarz
Guest
Posts: n/a

 12-06-2007
On Mon, 03 Dec 2007 08:58:28 +0000, Philip Potter <(E-Mail Removed)>
wrote:

>Barry Schwarz wrote:
>> On Fri, 30 Nov 2007 12:54:04 +0000, Philip Potter <(E-Mail Removed)>
>> wrote:
>>
>>> Barry Schwarz wrote:
>>>> On Wed, 28 Nov 2007 16:45:40 +0100, Björn Paetzel <(E-Mail Removed)>
>>>> wrote:
>>>>
>>>>> santosh schrieb:
>>>>>
>>>>>>> How can foo be 3 different things at the same time as in the
>>>>>>> original 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
>>>>>> expressions 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
Guest
Posts: n/a

 12-06-2007
Barry Schwarz wrote:
> On Mon, 03 Dec 2007 08:58:28 +0000, Philip Potter <(E-Mail Removed)>
> 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 <fj0v3n\$oks\$(E-Mail Removed)>, 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?

jameskuyper@verizon.net
Guest
Posts: n/a

 12-06-2007
Philip Potter wrote:
....
> 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?

This isn't strictly conforming; if LDBL_MAX < UINT_MAX, which is
technically possible for a conforming implementation, it will
overflow. In order for this to work, I need a signed or floating point
type capable of representing UINT_MAX, and the standard does not
require that any such type exist. However, I expect most people will
be willing to accept that limitation:

#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

Philip Potter
Guest
Posts: n/a

 12-06-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) 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
Guest
Posts: n/a

 12-09-2007
On Thu, 06 Dec 2007 13:14:19 +0000, Philip Potter <(E-Mail Removed)>
wrote:

>I came up with a very similar example in <fj0v3n\$oks\$(E-Mail Removed)>, 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