what will happen if we print the following...

[Shraddha]

int *s=(int *)2000;
int *p=(int *)1000;

printf("%d",p-s);

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

On 25 Maj, 14:47, Shraddha <[e-mail]:

int *s=(int *)2000;
int *p=(int *)1000;

printf("%d",p-s);

What do you think will happen?

By the way, this is probably better asked in comp.lang.c

--
Erik Wikström

[shadowman]

Shraddha wrote:

int *s=(int *)2000;
int *p=(int *)1000;

printf("%d",p-s);

This question doesn't make any sense. You'll take the time to post this
to a newsgroup, but you won't compile the code and see for yourself what
happens?

[Salt_Peter]

On May 25, 8:47 am, Shraddha <[e-mail]:

int *s=(int *)2000;
int *p=(int *)1000;

printf("%d",p-s);

What will happen is nowhere near as important as what the intention of
the code is. What are you trying to do?

[osmium]

"Salt_Peter" writes:

On May 25, 8:47 am, Shraddha <[e-mail]:

>int *s=(int *)2000;
int *p=(int *)1000;

printf("%d",p-s);

What will happen is nowhere near as important as what the intention of
the code is. What are you trying to do?

It looks to me like he is trying to learn the rules of some computer
language. And perhaps its interaction with its native habitat.

[Default User]

osmium wrote:

"Salt_Peter" writes:

On May 25, 8:47 am, Shraddha <[e-mail]:

int *s=(int *)2000;
int *p=(int *)1000;
>
printf("%d",p-s);

What will happen is nowhere near as important as what the intention
of the code is. What are you trying to do?

It looks to me like he is trying to learn the rules of some computer
language. And perhaps its interaction with its native habitat.

Learning a programming language, especially a large one like C++, by
random usenet posts is a fool's game. It wastes everyone's time.

He needs to get a decent book and work through it, asking questions
about things he can't figure out.


Brian

[James Kanze]

On May 25, 2:47 pm, Shraddha <[e-mail]:

int *s=(int *)2000;
int *p=(int *)1000;

printf("%d",p-s);

It depends very much on the implementation, and it could core
dump, or crash the system. On most systems, however, it will
probably output the value of 1000/sizeof(int).

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Salt_Peter]

On May 25, 3:07 pm, "osmium" <[e-mail]:

"Salt_Peter" writes:

On May 25, 8:47 am, Shraddha <[e-mail]:

int *s=(int *)2000;
int *p=(int *)1000;

printf("%d",p-s);

What will happen is nowhere near as important as what the intention of
the code is. What are you trying to do?

It looks to me like he is trying to learn the rules of some computer
language. And perhaps its interaction with its native habitat.

Unfortunately, that appears to be the case (although i'ld replace
'rules' with 'effects'). I'ld suggest that setting pointers to
unallocated memory using magic numbers is begging for a whiplashing.
Calculating the offset between 2 memory locations and dividing a
hypothetical sizeof(int) is not a constructive discussion for the OP.
Thats not what C++ is about, IMHO.

He might as well do:
#include <iostream>

int main()
{
size_t t(1000);
std::cout << t/sizeof(int) << std::endl;
}

I'ld rather he come forth and explain the purpose or expectations of
the code before we start hitting him with semantics (prefer
static_cast<>() to old casts, magic pointers are evil, etc).

[osmium]

"Shraddha" wrote:

int *s=(int *)2000;
int *p=(int *)1000;

printf("%d",p-s);

You would do well to compile this, run it, see what happens and remeber it.
#include <stdio.h>

int main(void)
{
double x = 1.e35;
int n;
n = (int) x;
printf("%d\n", n);
return 0;
}

The message is clear. A cast says: "compiler, do this conversion. I am a
smart human and I know what I am doing." The compiler believes you and does
its best to comply. The results may be nonsense, which is what I get on my
compiler. It prints -250. The compilers I have used say "can not convert'
in the pre-cast error message. It really means: I *will not*, unless you
explicitly tell me to.

[osmium]

"osmium" writes:

#include <stdio.h>

int main(void)
{
double x = 1.e35;
int n;
n = (int) x;
printf("%d\n", n);
return 0;
}

Oops. That's C code, I read it as a C problem and answered accordingly.

[James Kanze]

On May 26, 1:14 am, "osmium" <[e-mail]:

"Shraddha" wrote:

int *s=(int *)2000;
int *p=(int *)1000;

printf("%d",p-s);

You would do well to compile this, run it, see what happens and remeber it.

#include <stdio.h>

int main(void)
{
double x = 1.e35;
int n;
n = (int) x;
printf("%d\n", n);
return 0;
}

You would do well *not* to try to run such a program. It's
undefined behavior, and there is no guarantee with regards as to
what might happen.

Rather than playing around, it would be well to learn the
language. Or even basic principles: I know of know language
where such conversions do anything useful---they're either
undefined behavior, as in C/C++, or they are guaranteed to stop
the program. A good programmer verifies before converting,
always.

The message is clear.
A cast says: "compiler, do this conversion. I am a
smart human and I know what I am doing."

The cast, in this case, changes absolutely nothing, since it is
an implicite conversion. At best, it might shut up a warning,
although for various more or less historical reasons, very few
compilers warn about lossy conversions.

The compiler believes you and does its best to comply.

I'd express it differently: the compiler supposes that you know
what you are doing (cast or not), and that if you are assigning
a double to an int, you have verified that it won't overflow.
So it takes no precautions for such an eventuality.

The results may be nonsense, which is what I get on my
compiler. It prints -250. The compilers I have used say "can
not convert' in the pre-cast error message. It really means:
I *will not*, unless you explicitly tell me to.

What compiler is this? Double to int is a perfectly legal
conversion, and the compiler is required to compile the code.
(Actually, not in this case, because even the simplest optimizer
will immediatly determine that the conversion will overflow, and
that the program will contain undefined behavior, regardless of
the input. But in general, this is not verifiable at compile
time.)

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]