Is the following code OK?

**junky_fellow@yahoo.co.in** · Nov 15 '05, 01:38 AM

Re: Is the following code OK?

vb@gmail.com wrote:[color=blue]
> 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 )[/color]
<snip>

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

**Eric Sosman** · Nov 15 '05, 01:38 AM

Re: Is the following code OK?

vb@gmail.com wrote:[color=blue]
> 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 ?[/color]

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 <, <=,[color=blue]
>=, > can only be applied to pointers that designate locations[/color]
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
esosman@acm-dot-org.invalid

**RAJU** · Nov 15 '05, 01:38 AM

Re: Is the following code OK?

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:[color=blue]
> vb@gmail.com wrote:[color=green]
> > 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 ?[/color]
>
> 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 <, <=,[color=green]
> >=, > can only be applied to pointers that designate locations[/color]
> 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
> esosman@acm-dot-org.invalid[/color]

**junky_fellow@yahoo.co.in** · Nov 15 '05, 01:38 AM

Re: Is the following code OK?

Eric Sosman wrote:[color=blue]
> vb@gmail.com wrote:[color=green]
> > 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 ?[/color]
>
> 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 <, <=,[color=green]
> >=, > can only be applied to pointers that designate locations[/color]
> 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
> esosman@acm-dot-org.invalid[/color]

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** · Nov 15 '05, 01:39 AM

Re: Is the following code OK?

junky_fellow@ya hoo.co.in wrote:[color=blue]
> Eric Sosman wrote:[color=green]
>> [...]
>> The next problem is that the relational operators <, <=,[color=darkred]
>> >=, > can only be applied to pointers that designate locations[/color]
>>in (or just after) the same array. [...][/color]
>
> 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) ?[/color]

No. It is legal to test for equality with == or !=, but
non-portable to test for order with <, <=, >=, >.
[color=blue]
> Secondly, can we compare two pointers that are pointing to the
> two different members of a structure ?[/color]

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.
[color=blue]
> 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 ?[/color]

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.
[color=blue]
> I think, comparing (c1 < c2) is more appropriate.[/color]

Yes, that's perfectly all right. So is

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

because of the "same aggregate" rule.

--
Eric.Sosman@sun .com

**Eric Sosman** · Nov 15 '05, 01:39 AM

Re: Is the following code OK?

Eric Sosman wrote:[color=blue]
>
> junky_fellow@ya hoo.co.in wrote:[color=green]
>> [...]
>>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);[/color][/color]

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 '.

--
Eric.Sosman@sun .com

**Robert Gamble** · Nov 15 '05, 01:39 AM

Re: Is the following code OK?

junky_fellow@ya hoo.co.in wrote:[color=blue]
> Eric Sosman wrote:[color=green]
> > vb@gmail.com wrote:[/color][/color]

[snip]
[color=blue]
> 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) ?[/color]

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.
[color=blue]
> Secondly, can we compare two pointers that are pointing to the
> two different members of a structure ?[/color]

Yes, because they both point inside the same aggregate object (the
structure).
[color=blue]
> 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 ?[/color]

Correct, they are not compatible types so you cannot compare them.
[color=blue]
> I think, comparing (c1 < c2) is more appropriate.[/color]

That's fine.

Robert Gamble

**Keith Thompson** · Nov 15 '05, 01:39 AM

Re: Is the following code OK?

junky_fellow@ya hoo.co.in writes:[color=blue]
> Eric Sosman wrote:[/color]
[...][color=blue][color=green]
>> The next problem is that the relational operators <, <=,[color=darkred]
>> >=, > can only be applied to pointers that designate locations[/color]
>> 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 */[/color][/color]
[...][color=blue]
> 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) ?[/color]

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.
[color=blue]
> 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.[/color]

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) kst-u@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** · Nov 15 '05, 01:39 AM

Re: Is the following code OK?

Eric Sosman <eric.sosman@su n.com> writes:[color=blue]
> junky_fellow@ya hoo.co.in wrote:[/color]
[...][color=blue][color=green]
>> Secondly, can we compare two pointers that are pointing to the
>> two different members of a structure ?[/color]
>
> 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.[/color]

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) kst-u@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.

**Lawrence Kirby** · Nov 15 '05, 01:39 AM

Re: Is the following code OK?

On Mon, 08 Aug 2005 06:17:17 -0700, RAJU wrote:
[color=blue]
> 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.[/color]

Addresses may not be the same in different runs of the program but they
must remain consistent in the same run.
[color=blue]
> 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.[/color]

On virtual memory systems the physical address may change or the data may
be paged out of memory altogether. However the virtual address remains the
same and the virtual address is the important one i.e. what the program
sees.

Lawrence

**Peter Pichler** · Nov 15 '05, 01:40 AM

Re: Is the following code OK?

Eric Sosman wrote:
[color=blue]
> 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.[/color]

Literals starting with 0x are unsigned. An implementation may decide to
assign them to a signed variable without warning, but on their own they
are unsigned.

Peter

**junky_fellow@yahoo.co.in** · Nov 15 '05, 01:40 AM

Re: Is the following code OK?

Keith Thompson wrote:[color=blue]
> Eric Sosman <eric.sosman@su n.com> writes:[color=green]
> > junky_fellow@ya hoo.co.in wrote:[/color]
> [...][color=green][color=darkred]
> >> Secondly, can we compare two pointers that are pointing to the
> >> two different members of a structure ?[/color]
> >
> > 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.[/color]
>
> 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".
>[/color]

You have used the word "just past" the end of array (i.e. the next
element
beyond the end of array). Is this true for elements beyond that (next
to next
element beyond the end of array)?
[color=blue]
> #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;
> }[/color]

**Krishanu Debnath** · Nov 15 '05, 01:40 AM

Re: Is the following code OK?

junky_fellow@ya hoo.co.in wrote:[color=blue]
> Keith Thompson wrote:[color=green]
> > Eric Sosman <eric.sosman@su n.com> writes:[color=darkred]
> > > junky_fellow@ya hoo.co.in wrote:[/color]
> > [...][/color][/color]

<snip>
[color=blue][color=green]
> >
> > 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".
> >[/color]
>
> You have used the word "just past" the end of array (i.e. the next
> element
> beyond the end of array). Is this true for elements beyond that (next
> to next
> element beyond the end of array)?
>[/color]

Where is Mr.Dan Pop?

--
"Engage your ......"

**pete** · Nov 15 '05, 01:40 AM

Re: Is the following code OK?

junky_fellow@ya hoo.co.in wrote:[color=blue]
>
> Keith Thompson wrote:[/color]
[color=blue][color=green]
> > 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".
> >[/color]
>
> You have used the word "just past" the end of array (i.e. the next
> element
> beyond the end of array). Is this true for elements beyond that (next
> to next
> element beyond the end of array)?[/color]

No.
[color=blue][color=green]
> > #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;
> > }[/color][/color]

--
pete

Is the following code OK?

Is the following code OK?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment