Pointers in C

[Richard Tobin]

We know from the original post that the result is 1 without the casts
to char *. So unless sizeof(char *) is negative (an interesting idea)
the difference after casting will also be positive.

[/QUOTE]

Not necessarily. Did you see Flash Gordon's post (Message ID:
<[email protected]>) when he ran it on a AIX 5.3
machine? It gave -1 as the answer. Two different platforms gives two
different answers, both compiled with gcc.

Read what I wrote. "We know from the original post that the result is
1". The original poster ran the program and that's what he got. I
then said "If the system the OP is using [has various properties]
....". I am describing what the OP's system will produce, not what
some other gcc system will produce.

As most of us here know, undefined behavior is undefined behavior:
anything can happen, any result is possible. It all depends on your
implementation, compiler, and platform.

That's why I spelt out various assumptions. Given those assumptions,
what I said is true.

-- Richard

 

[santosh]

At about the time of 2/20/2007 10:11 PM, Praveen stated the following:

It's undefined behavior for reasons that others have pointed out.

In this case, x and y are placed ajacent in memory, so the difference is
1 since you are subtracting int pointers. Some people here have had -1
on their systems.

strata:/home/dr2867/c/test 1062 $$$ ->cat ub001.c

#include <stdio.h>

int main(void)
{
int x;
int y;
int *p1 = &x;
int *p2 = &y;
printf("%d\n", p1 - p2);

The ld format specifier might be a safer option. If you know your
implementation supports C99, then the tx or td format specifier would
be appropriate.

printf("p1 = %0#x\np2 = %0#x\n", (unsigned int)p1, (unsigned int)p2);

Why not simply?

printf("p1 = %p\np2 = %p\n", (void *)p1, (void *)p2);

 

[Keith Thompson]

Not necessarily. Did you see Flash Gordon's post (Message ID:
<[email protected]>) when he ran it on a AIX 5.3
machine? It gave -1 as the answer. Two different platforms gives two
different answers, both compiled with gcc.

Read what I wrote. "We know from the original post that the result is
1". The original poster ran the program and that's what he got. I
then said "If the system the OP is using [has various properties]
...". I am describing what the OP's system will produce, not what
some other gcc system will produce.

As most of us here know, undefined behavior is undefined behavior:
anything can happen, any result is possible. It all depends on your
implementation, compiler, and platform.

That's why I spelt out various assumptions. Given those assumptions,
what I said is true.[/QUOTE]

I, for one, did not assume that the presented output was part of your
assumptions. I though you were drawing a conclusion based only on
your stated assumptions. It's entirely possible I misread your
article; I'm too lazy to go back and check.

 

[Keith Thompson]

Daniel Rudy wrote: [...]

#include <stdio.h>

int main(void)
{
int x;
int y;
int *p1 = &x;
int *p2 = &y;
printf("%d\n", p1 - p2);

The ld format specifier might be a safer option.

"%ld" is really no safer than "%d". You need to convert the ptrdiff_t
result to a known type before printing it:

printf("%ld\n", (long)(p1 - p2));

 

[Daniel Rudy]

At about the time of 2/23/2007 9:34 AM, santosh stated the following:

The ld format specifier might be a safer option. If you know your
implementation supports C99, then the tx or td format specifier would
be appropriate.

You snipped my gcc command line, but I use -ansi and -std=c89 for my
language options. Gcc didn't give any warnings about my code, so I left
it as is.

Why not simply?

printf("p1 = %p\np2 = %p\n", (void *)p1, (void *)p2);

Because I was experimenting with it.

--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep

 

[Flash Gordon]

Daniel Rudy wrote, On 24/02/07 12:43:

At about the time of 2/23/2007 9:34 AM, santosh stated the following:

You snipped my gcc command line, but I use -ansi and -std=c89 for my
language options. Gcc didn't give any warnings about my code, so I left
it as is.

The compiler is not required to warn about miss-matches between format
specifiers and the corresponding options, with gcc I believe there is an
extra switch that will make it diagnose simple cases, but it cannot test
all possibilities. Also, the type might happen to be int, it just is not
guaranteed.

Because I was experimenting with it.

As long as there is a good reason ;-)


Using unsigned long would have been closer to portable, since on some 64
bit systems pointers are 64 bit but int and unsigned int are only 32
bit. %p as suggested above is of course always suitable.

 

[Daniel Rudy]

At about the time of 2/23/2007 9:05 AM, Richard Tobin stated the following:

Not necessarily. Did you see Flash Gordon's post (Message ID:
<[email protected]>) when he ran it on a AIX 5.3
machine? It gave -1 as the answer. Two different platforms gives two
different answers, both compiled with gcc.

Read what I wrote. "We know from the original post that the result is
1". The original poster ran the program and that's what he got. I
then said "If the system the OP is using [has various properties]
...". I am describing what the OP's system will produce, not what
some other gcc system will produce.[/QUOTE]

Sorry, I didn't catch it until after I hit the send button.

That's why I spelt out various assumptions. Given those assumptions,
what I said is true.

-- Richard

--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep