pointer initialization

[prakashraovaddina]

Hi ppl,
can some one say if the following pointer initialization is legal or
no.

int *intPtr = 5;

While debugging i still see that the pointer is given some address.
However, the initialization value is not found there. But, the
following string initialization,

char *charPtr = "this is a test string";

is just fine. The charPtr is pointing to the address location of the
value, "this is a test string".

thank you,
Prakash

[Chris Dollin]

pr************* **@googlemail.c om wrote:

can some one say if the following pointer initialization is legal or
no.

int *intPtr = 5;

No, it's not legal. `5` isn't a pointer value (and it hasn't been
obtained from a pointer value). The compiler should generate a
diagnostic. The behaviour of the code, if the compiler is
(un)helpful enough to generate it, isn't specified by the C
standard. (Your implementation may say what it does.)

While debugging i still see that the pointer is given some address.
However, the initialization value is not found there.

I don't understand what you mean. Be specific.

But, the following string initialization,

char *charPtr = "this is a test string";

Which is legal, and assigns to `charPtr` the address of
some static store initialised to contain the characters
of the string (with a terminating 0).

is just fine.

Good.

The charPtr is pointing to the address location of the
value, "this is a test string".

Yes.

--
Chris "electric hedgehog" Dollin
"Go not to the Elves for counsel, for they will answer both no and yes"
/The Lord of the Rings/

[raxitsheth2000]

On Feb 27, 2:43 pm, prakashraovadd. ..@googlemail.c om wrote:

Hi ppl,
can some one say if the following pointer initialization is legal or
no.

int *intPtr = 5;

your leftside is int* , right side is int, you should get warning
telling that you should cast.

>
While debugging i still see that the pointer is given some address.
However, the initialization value is not found there. But, the

intPtr is memory location and it will point to memory location 5,
if you try to find address of intPtr it will be different value, see
this.
#include<stdio. h>
#include<stdlib .h>

int main()
{

int *intPtr = 5; <---Casting Warning
char *charPtr = "this is a test string";

/* here intPtr is NOT EQAUL to &intPtr */

printf("\n%p",& intPtr);
printf("\n%p\n" ,intPtr);

return 0;
}
output :

0xbffed8e4 <--some address
0x5

------

following string initialization,

char *charPtr = "this is a test string";

is just fine. The charPtr is pointing to the address location of the
value, "this is a test string".

thank you,
Prakash

[Chris Dollin]

ra************@ yahoo.co.in wrote:

On Feb 27, 2:43 pm, prakashraovadd. ..@googlemail.c om wrote:

>Hi ppl,
can some one say if the following pointer initialization is legal or
no.

int *intPtr = 5;

your leftside is int* , right side is int, you should get warning
telling that you should cast.

No, you should get a diagnostic [warning or not] that says /what you're
doing is wrong/. It shouldn't tell you to cast, because that's usually
/not/ the right answer to a type mismatch: the thing to do with a type
mismatch is to /fix the mismatch/.

If the OP really wants to make a pointer-to-int which points to
location 5 (wherever that is -- and /which/ location 5 would that
be, sir? Aligned how, exactly?) on his machine, and his implementation
allows him to do that, then a cast might be the right answer. But
the OP hasn't explained why they're playing typing games, so we
don't know that the premise is true, and I believe it to be false.

In any case, casting at whim is a problem, not a solution. Yes?

--
Chris "electric hedgehog" Dollin
"Go not to the Elves for counsel, for they will answer both no and yes"
/The Lord of the Rings/

[raxitsheth2000]

On Feb 27, 4:19 pm, Chris Dollin <chris.dol...@h p.comwrote:

raxitsheth2...@ yahoo.co.in wrote:

On Feb 27, 2:43 pm, prakashraovadd. ..@googlemail.c om wrote:

Hi ppl,
can some one say if the following pointer initialization is legal or
no.

int *intPtr = 5;

your leftside is int* , right side is int, you should get warning
telling that you should cast.

No, you should get a diagnostic [warning or not] that says /what you're
doing is wrong/. It shouldn't tell you to cast, because that's usually
/not/ the right answer to a type mismatch: the thing to do with a type
mismatch is to /fix the mismatch/.

I agree, you used correct/more accurate words.on gcc i got following.
warning: initialization makes pointer from integer without a cast

>
If the OP really wants to make a pointer-to-int which points to
location 5 (wherever that is -- and /which/ location 5 would that
be, sir? Aligned how, exactly?) on his machine, and his implementation
allows him to do that, then a cast might be the right answer. But
the OP hasn't explained why they're playing typing games, so we
don't know that the premise is true, and I believe it to be false.

In any case, casting at whim is a problem, not a solution. Yes?

Not in all case, as you give the description above,

>
--
Chris "electric hedgehog" Dollin
"Go not to the Elves for counsel, for they will answer both no and yes"
/The Lord of the Rings/

--Raxit

[mark_bluemel]

On Feb 27, 9:43 am, prakashraovadd. ..@googlemail.c om wrote:

Hi ppl,
can some one say if the following pointer initialization is legal or
no.

int *intPtr = 5;

I can say if it's legal or not. It's not legal. If the compiler allows
it, it's almost certain not to do what I think you want.

While debugging i still see that the pointer is given some address.
However, the initialization value is not found there. But, the
following string initialization,

char *charPtr = "this is a test string";

is just fine. The charPtr is pointing to the address location of the
value, "this is a test string".

Actually, charPtr is pointing to the initial 't' of the string.
charPtr is a pointer to char, not a pointer to string. This is an
important distinction. Strings don't "really" exist in C.

If you wanted (as I suspect) intPtr to point to an int containing a
value of 5, you'd have to do it in two steps, e.g.

int theValue = 5;
int *intPtr = &intValue;

You probably need to do some more reading of a good text book on C.

[CBFalconer]

pr************* **@googlemail.c om wrote:

>
can some one say if the following pointer initialization is legal
or no.

int *intPtr = 5;

Converting an integer to a pointer is implementation defined. The
answer is no.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

[Chris Dollin]

ra************@ yahoo.co.in wrote:

On Feb 27, 4:19 pm, Chris Dollin <chris.dol...@h p.comwrote:

>If the OP really wants to make a pointer-to-int which points to
location 5 (wherever that is -- and /which/ location 5 would that
be, sir? Aligned how, exactly?) on his machine, and his implementation
allows him to do that, then a cast might be the right answer. But
the OP hasn't explained why they're playing typing games, so we
don't know that the premise is true, and I believe it to be false.

>In any case, casting at whim is a problem, not a solution. Yes?

Not in all case, as you give the description above,

In that case it isn't at whim; it's because it would be the [1]
correct thing to do.

[1] Or "a".

--
Chris "electric hedgehog" Dollin
"It was the first really clever thing the King had said that day."
/Alice in Wonderland/

[Keith Thompson]

CBFalconer <cb********@yah oo.comwrites:

pr************* **@googlemail.c om wrote:

>>
can some one say if the following pointer initialization is legal
or no.

int *intPtr = 5;

Converting an integer to a pointer is implementation defined. The
answer is no.

The result of such a conversion is implementation-defined, but no such
conversion is specified here. Some compilers (including gcc) will do
the conversion implicitly, but they're still required to issue a
diagnostic for the constraint violation; gcc's warning message is
sufficient as far as the standard is concerned.

If a compiler chooses to accept the above declaration, it's doing so
as part of an extension, something beyond what the language specifies.
Such an extension will *probably* do the equivalent of:

int *intPtr = (int*)5;

and I suspect that all compilers that allow this do just that, but in
principle it could do anything. It could even allocate space for an
int object and set intPtr to point to it, resulting in (*intPtr == 5)
(I don't believe any compilers actually do that). Or it could make
demons fly out of your nose. Once you've violated a constraint, the
behavior is undefined (but an implementation can choose to define the
behavior).

If you want to initialize intPtr to the address corresponding to the
number 5, the *first* thing you should do is stop and think about why
you want to do this. Chances are you don't. If you do have a good
reason, you should use a cast (an explicit conversion).

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Keith Thompson wrote:

CBFalconer <cb********@yah oo.comwrites:

>pr************* **@googlemail.c om wrote:

>>>
can some one say if the following pointer initialization is legal
or no.

int *intPtr = 5;

Converting an integer to a pointer is implementation defined. The
answer is no.

The result of such a conversion is implementation-defined, but no such
conversion is specified here. ....

Oh? I see an object intPtr, of type pointer to int, being
initialized with the value 5, which is an integer.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>