Is the following code OK?

[vb]

hi all,
I have to compare an address of structure with an absolute address(this
address signifies the start of a memory component).
Now my question is the follwong code leagal:-

#include <stdio.h>

int main()
{
struct t{
int a;
int b;
}temp;

struct t* ptr=&temp;

if(ptr<0x120000 )
printf("What\n" );
else
printf("The hell\n");
return 0;
}

My concern is the comparision in the if statement because a structure
pointer and an unsigned int are being compared. Can there be an
undefined behaviour in any cases ?

[junky_fellow]

[e-mail] wrote:

hi all,
I have to compare an address of structure with an absolute address(this
address signifies the start of a memory component).
Now my question is the follwong code leagal:-

#include <stdio.h>

int main()
{
struct t{
int a;
int b;
}temp;

struct t* ptr=&temp;

if(ptr<0x120000 )

<snip>

The above comparison requires integer to pointer conversion, which
is implementation specific.

[Eric Sosman]

[e-mail] wrote:

hi all,
I have to compare an address of structure with an absolute address(this
address signifies the start of a memory component).
Now my question is the follwong code leagal:-

#include <stdio.h>

int main()
{
struct t{
int a;
int b;
}temp;

struct t* ptr=&temp;

if(ptr<0x120000 )
printf("What\n" );
else
printf("The hell\n");
return 0;
}

My concern is the comparision in the if statement because a structure
pointer and an unsigned int are being compared. Can there be an
undefined behaviour in any cases ?
There are (at least) two errors in the comparison, and
one misunderstandin g. The misunderstandin g first: 0x120000
is probably not an unsigned int. "Probably" because is is
up to the compiler to choose an appropriate type for each
literal constant, and different compilers use different bit
counts for the various integer types. The type of 0x120000
will be the first of { int, unsigned int, long, unsigned long,
long long, unsigned long long } that can represent its value,
and on most systems this will turn out to be either int or
long. As far as I can see, 0x120000 could be an unsigned int
only on a machine with 21-bit integers.

Pedantic digressions aside, on to the substantive problems.
First, as you suspect, it is not possible to compare a pointer
to any flavor of integer, except for the special case of an
integer constant zero (which signifies a null pointer). Pointers
are not numbers; numbers are not pointers. You are trying to
compare apples and orangutans.

You could try to rescue the situation by converting the
integer to a pointer by writing (struct t*)0x120000, but this
doesn't really solve anything even though it may cause the
compiler to stop complaining. The first difficulty is that
even though a cast operator can convert an integer to a pointer
(and vice-versa), the result of the conversion is implementation-
defined and need not be meaningful. In particular, it need not
produce a valid, usable result. You can, if you like, declare
that one orangutan converts to twelve and a half apples and then
claim you've compared them, but such capriciousness is not very
useful: neither the apple nor the orangutan pays any attention
to such nonsensical declarations. They were different to begin
with, and different they remain despite silly babbling.

That said, many machines *do* provide useful conversions
between pointers and at least one kind of integer, so even if
the C language doesn't require anything meaningful you may get
some meaning anyhow. But you're still not out of the woods!
The conversion may produce a valid pointer, but it might not
be a valid `struct t*' pointer -- it might, for example, not
satisfy the alignment requirement for a `struct t' object.

Well, there are seventeen low-order zero bits in the integer
you're using, so the likelihood of misalignment is vanishingly
small. Are we safe yet? Well, no. (What did you expect? ;-)

The next problem is that the relational operators <, <=,=, > can only be applied to pointers that designate locations

in (or just after) the same array. That is

char buff1[100], buff2[100];
char *p = buff1, *q = buff1 + 20;
if (p < q) ... /* okay: both point into buff1 */
q = buff2;
if (p < q) ... /* no good: different arrays */

In your code, ptr points to the object temp (which is thought
of as a one-element array in this context), but 0x120000 even
after conversion is by no means guaranteed to point at or just
after temp. It points (if everything above has gone your way)
to some completely unrelated memory location, and the comparison
can produce completely silly results. (This "same array"
restriction applies to the relational operators but not to the
equality operators: you can use == and != on "unrelated" pointers,
you just can't establish which is "greater.") If you think for
a bit about how the subtraction of pointers is defined, all this
may begin to make some kind of sense.

Summary: Your code might work, once the required cast is
inserted. I'd go so far as to say it would probably work on
most machines. But you're relying on a whole slew of things that
are not guaranteed by the C language; in this sense the code is
neither "leagal" nor legal. Such code may be necessary nonetheless;
some tasks like system-specific memory management are beyond the
capabilities of fully portable C.

--
Eric Sosman
es*****@acm-dot-org.invalid

[RAJU]

Hi Eric,

Thanks for detailed explaination. Could you clarify me one thing?

Afte casting also, on same machine is the result deterministic? Why I'm
asking is, the pointer address will be virtual address and this may not
be same in different runs.

The &temp may not have same vlaue on the stack frame? If more process'
are running then page replacement can happen and the same value may not
be guarenteed.

Regards,
Raju

Eric Sosman wrote:

[e-mail] wrote:

hi all,
I have to compare an address of structure with an absolute address(this
address signifies the start of a memory component).
Now my question is the follwong code leagal:-

#include <stdio.h>

int main()
{
struct t{
int a;
int b;
}temp;

struct t* ptr=&temp;

if(ptr<0x120000 )
printf("What\n" );
else
printf("The hell\n");
return 0;
}

My concern is the comparision in the if statement because a structure
pointer and an unsigned int are being compared. Can there be an
undefined behaviour in any cases ?

There are (at least) two errors in the comparison, and
one misunderstandin g. The misunderstandin g first: 0x120000
is probably not an unsigned int. "Probably" because is is
up to the compiler to choose an appropriate type for each
literal constant, and different compilers use different bit
counts for the various integer types. The type of 0x120000
will be the first of { int, unsigned int, long, unsigned long,
long long, unsigned long long } that can represent its value,
and on most systems this will turn out to be either int or
long. As far as I can see, 0x120000 could be an unsigned int
only on a machine with 21-bit integers.

Pedantic digressions aside, on to the substantive problems.
First, as you suspect, it is not possible to compare a pointer
to any flavor of integer, except for the special case of an
integer constant zero (which signifies a null pointer). Pointers
are not numbers; numbers are not pointers. You are trying to
compare apples and orangutans.

You could try to rescue the situation by converting the
integer to a pointer by writing (struct t*)0x120000, but this
doesn't really solve anything even though it may cause the
compiler to stop complaining. The first difficulty is that
even though a cast operator can convert an integer to a pointer
(and vice-versa), the result of the conversion is implementation-
defined and need not be meaningful. In particular, it need not
produce a valid, usable result. You can, if you like, declare
that one orangutan converts to twelve and a half apples and then
claim you've compared them, but such capriciousness is not very
useful: neither the apple nor the orangutan pays any attention
to such nonsensical declarations. They were different to begin
with, and different they remain despite silly babbling.

That said, many machines *do* provide useful conversions
between pointers and at least one kind of integer, so even if
the C language doesn't require anything meaningful you may get
some meaning anyhow. But you're still not out of the woods!
The conversion may produce a valid pointer, but it might not
be a valid `struct t*' pointer -- it might, for example, not
satisfy the alignment requirement for a `struct t' object.

Well, there are seventeen low-order zero bits in the integer
you're using, so the likelihood of misalignment is vanishingly
small. Are we safe yet? Well, no. (What did you expect? ;-)

The next problem is that the relational operators <, <=,

>=, > can only be applied to pointers that designate locations

in (or just after) the same array. That is

char buff1[100], buff2[100];
char *p = buff1, *q = buff1 + 20;
if (p < q) ... /* okay: both point into buff1 */
q = buff2;
if (p < q) ... /* no good: different arrays */

In your code, ptr points to the object temp (which is thought
of as a one-element array in this context), but 0x120000 even
after conversion is by no means guaranteed to point at or just
after temp. It points (if everything above has gone your way)
to some completely unrelated memory location, and the comparison
can produce completely silly results. (This "same array"
restriction applies to the relational operators but not to the
equality operators: you can use == and != on "unrelated" pointers,
you just can't establish which is "greater.") If you think for
a bit about how the subtraction of pointers is defined, all this
may begin to make some kind of sense.

Summary: Your code might work, once the required cast is
inserted. I'd go so far as to say it would probably work on
most machines. But you're relying on a whole slew of things that
are not guaranteed by the C language; in this sense the code is
neither "leagal" nor legal. Such code may be necessary nonetheless;
some tasks like system-specific memory management are beyond the
capabilities of fully portable C.

--
Eric Sosman
es*****@acm-dot-org.invalid

[junky_fellow]

Eric Sosman wrote:

[e-mail] wrote:

hi all,
I have to compare an address of structure with an absolute address(this
address signifies the start of a memory component).
Now my question is the follwong code leagal:-

#include <stdio.h>

int main()
{
struct t{
int a;
int b;
}temp;

struct t* ptr=&temp;

if(ptr<0x120000 )
printf("What\n" );
else
printf("The hell\n");
return 0;
}

My concern is the comparision in the if statement because a structure
pointer and an unsigned int are being compared. Can there be an
undefined behaviour in any cases ?

There are (at least) two errors in the comparison, and
one misunderstandin g. The misunderstandin g first: 0x120000
is probably not an unsigned int. "Probably" because is is
up to the compiler to choose an appropriate type for each
literal constant, and different compilers use different bit
counts for the various integer types. The type of 0x120000
will be the first of { int, unsigned int, long, unsigned long,
long long, unsigned long long } that can represent its value,
and on most systems this will turn out to be either int or
long. As far as I can see, 0x120000 could be an unsigned int
only on a machine with 21-bit integers.

Pedantic digressions aside, on to the substantive problems.
First, as you suspect, it is not possible to compare a pointer
to any flavor of integer, except for the special case of an
integer constant zero (which signifies a null pointer). Pointers
are not numbers; numbers are not pointers. You are trying to
compare apples and orangutans.

You could try to rescue the situation by converting the
integer to a pointer by writing (struct t*)0x120000, but this
doesn't really solve anything even though it may cause the
compiler to stop complaining. The first difficulty is that
even though a cast operator can convert an integer to a pointer
(and vice-versa), the result of the conversion is implementation-
defined and need not be meaningful. In particular, it need not
produce a valid, usable result. You can, if you like, declare
that one orangutan converts to twelve and a half apples and then
claim you've compared them, but such capriciousness is not very
useful: neither the apple nor the orangutan pays any attention
to such nonsensical declarations. They were different to begin
with, and different they remain despite silly babbling.

That said, many machines *do* provide useful conversions
between pointers and at least one kind of integer, so even if
the C language doesn't require anything meaningful you may get
some meaning anyhow. But you're still not out of the woods!
The conversion may produce a valid pointer, but it might not
be a valid `struct t*' pointer -- it might, for example, not
satisfy the alignment requirement for a `struct t' object.

Well, there are seventeen low-order zero bits in the integer
you're using, so the likelihood of misalignment is vanishingly
small. Are we safe yet? Well, no. (What did you expect? ;-)

The next problem is that the relational operators <, <=,

>=, > can only be applied to pointers that designate locations

in (or just after) the same array. That is

char buff1[100], buff2[100];
char *p = buff1, *q = buff1 + 20;
if (p < q) ... /* okay: both point into buff1 */
q = buff2;
if (p < q) ... /* no good: different arrays */

In your code, ptr points to the object temp (which is thought
of as a one-element array in this context), but 0x120000 even
after conversion is by no means guaranteed to point at or just
after temp. It points (if everything above has gone your way)
to some completely unrelated memory location, and the comparison
can produce completely silly results. (This "same array"
restriction applies to the relational operators but not to the
equality operators: you can use == and != on "unrelated" pointers,
you just can't establish which is "greater.") If you think for
a bit about how the subtraction of pointers is defined, all this
may begin to make some kind of sense.

Summary: Your code might work, once the required cast is
inserted. I'd go so far as to say it would probably work on
most machines. But you're relying on a whole slew of things that
are not guaranteed by the C language; in this sense the code is
neither "leagal" nor legal. Such code may be necessary nonetheless;
some tasks like system-specific memory management are beyond the
capabilities of fully portable C.

--
Eric Sosman
es*****@acm-dot-org.invalid

Is it legal to compare two pointers to different objets ?
eg.
char *str1 = "abcd";
char *str2 = "efg";
then is it legal to compare (str1 < str2) ?

Secondly, can we compare two pointers that are pointing to the
two different members of a structure ?
For eg.
struct test {
int i1;
char * ptr;
int i2;
char c1;
char c2;
}

struct test str_test;
char *c1 = &(str_test.c 1);
int *i1 = &(str_test.i 1);
char *c2 = &(str_test.i 1);

Now, can we compare (i1 < c1) ? I have a doubt because types of i1
and c1 are different ?

I think, comparing (c1 < c2) is more appropriate.

[Eric Sosman]

ju**********@ya hoo.co.in wrote:

Eric Sosman wrote:

[...]
The next problem is that the relational operators <, <=,

>=, > can only be applied to pointers that designate locationsin (or just after) the same array. [...]

Is it legal to compare two pointers to different objets ?
eg.
char *str1 = "abcd";
char *str2 = "efg";
then is it legal to compare (str1 < str2) ?

No. It is legal to test for equality with == or !=, but
non-portable to test for order with <, <=, >=, >.
Secondly, can we compare two pointers that are pointing to the
two different members of a structure ?
Yes. I oversimplified when I wrote about pointers into
the same array. What's actually required is that they point
into or just after the same "aggregate object," which could
be an array, a struct, or a union.
For eg.
struct test {
int i1;
char * ptr;
int i2;
char c1;
char c2;
}

struct test str_test;
char *c1 = &(str_test.c 1);
int *i1 = &(str_test.i 1);
char *c2 = &(str_test.i 1);

Now, can we compare (i1 < c1) ? I have a doubt because types of i1
and c1 are different ?

The comparison is disallowed because the two pointers do
not have "compatible types." You could rescue it by rewriting
as `(char*)i1 < c1', essentially treating the struct object as
an array of bytes. Pointers to elements of that byte array
are comparable.
I think, comparing (c1 < c2) is more appropriate.

Yes, that's perfectly all right. So is

int *i2 = &str_test.i2 ;
if (i2 < i1) ...

because of the "same aggregate" rule.

--
Er*********@sun .com

[Eric Sosman]

Eric Sosman wrote:

ju**********@ya hoo.co.in wrote:

[...]
For eg.
struct test {
int i1;
char * ptr;
int i2;
char c1;
char c2;
}

struct test str_test;
char *c1 = &(str_test.c 1);
int *i1 = &(str_test.i 1);
char *c2 = &(str_test.i 1);

Oops: I missed this error on first reading. You're
trying to initialize a char* variable with an expression
whose type is int*, and since the two types are not
compatible a diagnostic is required. You'd need to
write `char *c2 = (char*)&str_tes t.i1', or perhaps what
I mis-read this as: `char *c2 = &str_test.c2 '.

--
Er*********@sun .com

[Robert Gamble]

ju**********@ya hoo.co.in wrote:

Eric Sosman wrote:

[e-mail] wrote:

[snip]
Is it legal to compare two pointers to different objets ?
eg.
char *str1 = "abcd";
char *str2 = "efg";
then is it legal to compare (str1 < str2) ?
Not unless both objects are part of an aggregate object.

(str1 == str2) and (str1 != str2) are legal,
(str1 < str2), (str1 > str2), (str1 <= str2), and (str1 >= str2) are
not.
Secondly, can we compare two pointers that are pointing to the
two different members of a structure ?
Yes, because they both point inside the same aggregate object (the
structure).
For eg.
struct test {
int i1;
char * ptr;
int i2;
char c1;
char c2;
}

struct test str_test;
char *c1 = &(str_test.c 1);
int *i1 = &(str_test.i 1);
char *c2 = &(str_test.i 1);

Now, can we compare (i1 < c1) ? I have a doubt because types of i1
and c1 are different ?
Correct, they are not compatible types so you cannot compare them.
I think, comparing (c1 < c2) is more appropriate.

That's fine.

Robert Gamble

[Keith Thompson]

ju**********@ya hoo.co.in writes:

Eric Sosman wrote: [...]

The next problem is that the relational operators <, <=,

>=, > can only be applied to pointers that designate locations

in (or just after) the same array. That is

char buff1[100], buff2[100];
char *p = buff1, *q = buff1 + 20;
if (p < q) ... /* okay: both point into buff1 */
q = buff2;
if (p < q) ... /* no good: different arrays */

[...] Is it legal to compare two pointers to different objets ?
eg.
char *str1 = "abcd";
char *str2 = "efg";
then is it legal to compare (str1 < str2) ?
It's legal in the sense that it's not a syntax error or a constraint
violation, so the implementation isn't required to complain about it,
but it invokes undefined behavior.
Secondly, can we compare two pointers that are pointing to the
two different members of a structure ?
For eg.
struct test {
int i1;
char * ptr;
int i2;
char c1;
char c2;
}

struct test str_test;
char *c1 = &(str_test.c 1);
int *i1 = &(str_test.i 1);
char *c2 = &(str_test.i 1);

Now, can we compare (i1 < c1) ? I have a doubt because types of i1
and c1 are different ?

I think, comparing (c1 < c2) is more appropriate.

Any object can be viewed as an array of characters. It's illegal (a
constraint violation requiring a compile-time diagnostic) to compare
pointers to incompatible types, so (i1 < c1) is illegal, but
((char*)i1 < c1) is ok and is guaranteed to yield 1.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Eric Sosman <er*********@su n.com> writes:

ju**********@ya hoo.co.in wrote:

[...]

Secondly, can we compare two pointers that are pointing to the
two different members of a structure ?

Yes. I oversimplified when I wrote about pointers into
the same array. What's actually required is that they point
into or just after the same "aggregate object," which could
be an array, a struct, or a union.

And for these purposes, a scalar object can be treated as a
single-element array. For example, the following program will always
print "ok"; ptr1 points just past the end of the "array".

#include<stdio. h>
int main()
{
int x;
int *ptr0 = &x;
int *ptr1 = &x + 1;
if (ptr1 > ptr0) {
printf("ok\n");
}
else {
printf("Somethi ng is broken\n");
}
return 0;
}

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.