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]

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.

 

[raxitsheth2000]

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

------

 

[Chris Dollin]

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?

 

[CBFalconer]

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.

 

[raxitsheth2000]

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,

--Raxit

 

[mark_bluemel]

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.

 

[Chris Dollin]

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

 

[Keith Thompson]

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

 

[CBFalconer]

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.

 

[Keith Thompson]

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

 

[Chris Torek]

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

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_answer(&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_answer((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.

 

[CBFalconer]

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.

 

[pete]

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.

 

[CBFalconer]

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_name", "index_of_slip_of_paper",
"date_of_creation", "type_of_object_pointed_to".

 

[Ben Pfaff]

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_answer((int []){42});

I think that the following is equivalent, and to my mind it is
logically simpler also:
SYS_set_the_answer(&(int){42});

 

[Flash Gordon]

CBFalconer wrote, On 28/02/07 14:19:

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_name", "index_of_slip_of_paper",
"date_of_creation", "type_of_object_pointed_to".

It can't, and as there is no implicit conversion defined in the C
standard and no explicit declaration defined in the code the compiler is
required to produce a diagnostic and not required to compile the code.
If the compiler chooses to compile the code then it could do anything,
including as one person suggested creating an object of type int, taking
its address, and putting that in intptr, in which case no conversion
would have taken place! This is probably what the OP actually expected
to happen based on the OP having also referred to string literals!

 

[Keith Thompson]

pete wrote: [...]

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.

Right (except that it can if a compiler provides that as an
extension).

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_name", "index_of_slip_of_paper",
"date_of_creation", "type_of_object_pointed_to".

Consider this:

int *bogus1 = 123.456;
int *bogus2 = { "foo", { 1, 2 }, 0xdeadbeef };

You're right, you can't stuff a value of type int, or of type double,
or of whatever type that last initializer might be, into an int*
without a conversion of some sort. The conclusion is not that there
must be a conversion. The conclusion is that you can't stuff the
value into an int*. It's a constraint violation. The standard
doesn't say that a conversion is going to take place. It could be
argued that the declaration (any of them) *isn't C*.

If a conforming compiler does accept the declaration of intptr, it's
because it implements an extension of some sort. That extension
*might* involve a conversion from int to int*, but it might not. For
all we know, the compiler could accept the literal 5 as a pointer
constant of type void* (whose value may or may not be equal to
(void*)5), or, as I mentioned upthread, it could create an object of
type int initialized to 5 and set intptr to point to it.