pointer initialization

[prakashraovaddina@googlemail.com]

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]

Re: pointer initialization

prakashraovaddi na@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@yahoo.co.in]

Re: pointer initialization

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]

Re: pointer initialization

raxitsheth2000@ 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@yahoo.co.in]

Re: pointer initialization

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@pobox.com]

Re: pointer initialization

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]

Re: pointer initialization

prakashraovaddi na@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]

Re: pointer initialization

raxitsheth2000@ 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]

Re: pointer initialization

CBFalconer <cbfalconer@yah oo.comwrites:

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

[CBFalconer]

Re: pointer initialization

Keith Thompson wrote:

CBFalconer <cbfalconer@yah oo.comwrites:

>prakashraovaddi na@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>

[Keith Thompson]

Re: pointer initialization

CBFalconer <cbfalconer@yah oo.comwrites:

Keith Thompson wrote:

>CBFalconer <cbfalconer@yah oo.comwrites:

>>prakashraovaddi na@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.

And what makes you think that the int value 5 is going to be
*converted* to type int*? Many implementations will do this as an
extension (most likely to cater to ancient pre-ANSI code), but the
standard doesn't say that such a conversion will take place.

C99 6.7.8, Initialization, p11:

The initializer for a scalar shall be a single expression,
optionally enclosed in braces. The initial value of the object is
that of the expression (after conversion); the same type
constraints and conversions as for simple assignment apply, taking
the type of the scalar to be the unqualified version of its
declared type.

C99 6.5.16.1, Simple assignment:

Constraints:

One of the following shall hold:
[...]

followed by a list of possibilities, none of which is met by
"int *intPtr = 5;".

If it *didn't* violate a constraint, then the semantics would be that
the value 5 is converted to int* and the result store in intPtr.

Though the standard doesn't explicitly say so as far as I can tell, my
understanding is that if a constraint is violated and the
implementation chooses to accept the translation unit anyway (after
issuing the required diagnostic), then the behavior of the resulting
program is undefined.

For example, if a (rather perverse) implementation chose in this case
to print a warning message, implicitly create an anonymous object of
type int, initialize it to 5, and set intPtr to the object's address
(note: not a conversion in sight), I believe that would be a
conforming implementation (with a bizarre, but legal, extension).

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

[Chris Torek]

Re: pointer initialization

[re "int *p = 5", which requires a diagnostic]

In article <lnirdn2uts.fsf @nuthaus.mib.or g>
Keith Thompson <kst-u@mib.orgwrote, in part:

>If a compiler chooses to accept the above declaration [after

producing a diagnostic] ...

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

Possibly not. On the other hand, at least one compiler -- the
C compiler on VMS -- did have an extension of the form:

&<constant>

which put the given constant into memory, and then produced the
address of the compiler-created object. This was done specifically
to allow VMS system calls that took the addresses of "int" values,
so that you could write, e.g.:

sys$set_the_ans wer(&42);

to invoke the system service call "set the answer" to set the answer
to 42. (System calls took the addresses of their values, instead
of taking the values directly, to make them convenient to call from
VMS Fortran, which passed all integer values by address. This, of
course, made them inconvenient to call from "normal" C, hence the
above extension.)

C could have been defined with syntax like this, and C99 adds an
equivalent: the VMS call could now be done with, e.g.:

#include <vms.h/* has #defines so we need not resort to "$" */
...
SYS_set_the_ans wer((int []){42});

which would be entirely portable except for the inclusion of <vms.h>,
and of course, the fact that no other OS has a "set the answer"
call. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[CBFalconer]

Re: pointer initialization

Keith Thompson wrote:

CBFalconer <cbfalconer@yah oo.comwrites:

>Keith Thompson wrote:

>>CBFalconer <cbfalconer@yah oo.comwrites:
>>>prakashraovaddi na@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.

>
And what makes you think that the int value 5 is going to be
*converted* to type int*? Many implementations will do this as an
extension (most likely to cater to ancient pre-ANSI code), but the
standard doesn't say that such a conversion will take place.

I think you are misreading my comment. I am objecting to the
underlined statement above.

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

[pete]

Re: pointer initialization

CBFalconer wrote:

>
Keith Thompson wrote:

CBFalconer <cbfalconer@yah oo.comwrites:

Keith Thompson wrote:
>CBFalconer <cbfalconer@yah oo.comwrites:
>>prakashraovaddi na@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.

And what makes you think that the int value 5 is going to be
*converted* to type int*? Many implementations will do this as an
extension (most likely to cater to ancient pre-ANSI code), but the
standard doesn't say that such a conversion will take place.

>
I think you are misreading my comment. I am objecting to the
underlined statement above.

I think Keith's point is that that assignment
doesn't, and is not supposed to,
cause the conversion of an int to a pointer.

For this definition:
int *intPtr = (int *)5;
the statement
"Converting an integer to a pointer is implementation defined."
applies.

--
pete

[CBFalconer]

Re: pointer initialization

pete wrote:

>
CBFalconer wrote:

Keith Thompson wrote:

CBFalconer <cbfalconer@yah oo.comwrites:
>Keith Thompson wrote:
>>CBFalconer <cbfalconer@yah oo.comwrites:
>>>prakashraovaddi na@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.
>
And what makes you think that the int value 5 is going to be
*converted* to type int*? Many implementations will do this as an
extension (most likely to cater to ancient pre-ANSI code), but the
standard doesn't say that such a conversion will take place.

I think you are misreading my comment. I am objecting to the
underlined statement above.

>
I think Keith's point is that that assignment
doesn't, and is not supposed to,
cause the conversion of an int to a pointer.

Repeating questionable declaration:

int *intptr = 5;

intptr is of type pointer to int. 5 is of type int. How can one
be stuffed into the other without comversion? intptr may require
fields such as "little_boys_na me", "index_of_slip_ of_paper",
"date_of_creati on", "type_of_object _pointed_to".

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