can you tell that y the code is work like that

[venkatesh]

int *p=20;
printf("%d",*p);
printf("%d",p);



the above code prints the output as
somegarbage value //for *p(may be address
20 //for p
why can you explain
thanks for that

 

[Christopher Benson-Manica]

int *p=20;

Broken. What makes you suspect that 20 is an appropriate value for a
pointer to an integer?

printf("%d",*p);

Broken. What exactly do you think a pointer with the value 20 might
point to?

printf("%d",p);

Broken. The size of a pointer to an integer need not be equal to
sizeof(int).

printf( "%p", (void*)p );

why can you explain

Pure random chance, as far as the C standard is concerned.

 

[Pierre Maurette]

venkatesh, le 21/10/2005, a écrit :

int *p=20;
printf("%d",*p);
printf("%d",p);



the above code prints the output as
somegarbage value //for *p(may be address
20 //for p
why can you explain
thanks for that

int dummy = 20;
int* p = &dummy;
printf("%d\n",*p);
printf("%p\n",p);

or

int* p = malloc(sizeof int);
*p = 20;
printf("%d\n",*p);
printf("%p\n",p);

 

[Emmanuel Delahaye]

venkatesh a écrit :

int *p=20;

This is kinda nonsense. What to you think it meant ?

The portable way of initializing a pointer to an object are

- NULL
- The address of an object of the same type
- the value returned by malloc()
- the value returned by fopen() if the type is void* or FILE*
and similar cases.

But initialising a pointer with a plain integer is undefined by the
language. Actually, it may work on a specific platform. It's called an
implementation-dependent behaviour.

 

[vire]

yes,
exactly what you wrote means:
int* p;
p = 20;

 

[Default User]

yes,
exactly what you wrote means:
int* p;
p = 20;

Please read my .sig.


Brian

 

[Keith Thompson]

Broken. What makes you suspect that 20 is an appropriate value for a
pointer to an integer?

What's surprising is that his compiler thought it was appropriate.

A compiler might allow assigning an integer value to a pointer as an
extension, but if the code is compiled in strict mode (might be called
"ansi" or "iso", depending on the compiler), the compiler is required
to issue a diagnostic.

[...]

Broken. The size of a pointer to an integer need not be equal to
sizeof(int).

Size matters not. Using "%d" to print a pointer value invokes
undefined behavior (though it will often do what you expect anyway).
It can fail even if int and int* happen to have the same size.

The correct way to print an int* value is:

printf("%p", (void*)p);

Also, the original code, if it doesn't blow up, will probably print
the values adjacent to each other; you won't be able to tell where one
ends and the other begins. Rather than

int *p=20;
printf("%d",*p);
printf("%d",p);

you might try this:

int *p = (int*)20;
printf("*p = %d\n", *p);
printf("p = %p\n", (int*)p);

Of course this could still invoke undefined behavior, since (int*)20
is unlikely to be a valid address.

Here's a program that actually works:

#include <stdio.h>
#include <stdlib.h>
int main (void)
{
int *p = malloc(sizeof *p);
if (p == NULL) {
printf("malloc failed\n");
}
else {
*p = 20;
printf("*p = %d\n", *p);
printf("p = %p\n", (void*)p);
}
return 0;
}

 

[Christopher Benson-Manica]

The correct way to print an int* value is:

printf("%p", (void*)p);

(which I did mention, FWIW)

Of course this could still invoke undefined behavior, since (int*)20
is unlikely to be a valid address.

Is it not UB regardless, since 20 is not a value obtained from
malloc()?

 

[Tim Rentsch]

venkatesh a écrit :

This is kinda nonsense. What to you think it meant ?

The portable way of initializing a pointer to an object are

- NULL
- The address of an object of the same type
- the value returned by malloc()
- the value returned by fopen() if the type is void* or FILE*
and similar cases.

And 0 (or any 0-valued constant expression).

But initialising a pointer with a plain integer is undefined by the
language.

Unless the integer is 0.

 

[Keith Thompson]

(which I did mention, FWIW)
Ok.


Is it not UB regardless, since 20 is not a value obtained from
malloc()?

Valid pointers don't have to be obtained from malloc().

The conversion itself yields an implementation-defined result:

An integer may be converted to any pointer type. Except as
previously specified, the result is implementation-defined, might
not be correctly aligned, might not point to an entity of the
referenced type, and might be a trap representation.

with a footnote:

The mapping functions for converting a pointer to an integer or an
integer to a pointer are intended to be consistent with the
addressing structure of the execution environment.

If the result happens to be an invalid pointer, dereferencing it
invokes undefined behavior. If the implementation happens to
guarantee that 20 is a valid address for an int, the behavior of
dereferencing (int*)20 is merely implementation-defined.

 

[Emmanuel Delahaye]

Tim Rentsch a écrit :

And 0 (or any 0-valued constant expression).

Unless the integer is 0.

NULL was supposed to cover the case...

 

[Tim Rentsch]

Tim Rentsch a écrit :



NULL was supposed to cover the case...

I guessed that might have been the intention; however,
NULL is not guaranteed to be 0, and typically in fact
it isn't.

 

[Jordan Abel]

I guessed that might have been the intention; however,
NULL is not guaranteed to be 0, and typically in fact
it isn't.

It's not guaranteed to be all-bits-zero, but that's not what he claimed. It
might be ((void *)0) or something like that, but i very much doubt anyone has
it as ((void *)0xdeadbeef), especially given that NULL _is_ guaranteed to
become 0 when converted to an integer

 

[Keith Thompson]

It's not guaranteed to be all-bits-zero, but that's not what he claimed. It
might be ((void *)0) or something like that, but i very much doubt anyone has
it as ((void *)0xdeadbeef), especially given that NULL _is_ guaranteed to
become 0 when converted to an integer

No, I don't believe it is.

If NULL is defined as 0, then of course it's already of type int. But
if NULL is defined as (void*)0, then it's an expression of type void*,
and there's no guarantee that converting it to int will yield the
value 0.

The only specific guarantee is that a null pointer constant converted
to a pointer type yields a null pointer, and that only applies at
compilation time.

 

[Jordan Abel]

No, I don't believe it is.

If NULL is defined as 0, then of course it's already of type int.
But if NULL is defined as (void*)0, then it's an expression of
type void*, and there's no guarantee that converting it to int
will yield the value 0.

I could have sworn that there was a guarantee that null pointers
(constant or otherwise) convert to zero

how does if(p) work, then? if(p != 0) can be explained by the 0
being converted to a null pointer, and !p is defined as 0==p but i
could have sworn the argument in a conditional had to be an integer
type

The only specific guarantee is that a null pointer constant
converted to a pointer type yields a null pointer, and that only
applies at compilation time.

actually, though i could find nothing supporting my belief about
conversions to integer, apparently (from my interpretation)
conversions from any null pointer to any pointer type [at least, any
that the original pointer type is allowed to be converted to - void
pointer and pointer types with 'less strict alignment'] yield a null
pointer - constant or otherwise. It doesn't actually say that, but
you can get as far as "will compare equal [with the original null
pointer]" from other statements, and it seems implied that any
pointer that will compare equal with a null pointer is a null
pointer.

 

[Tim Rentsch]

It's not guaranteed to be all-bits-zero, but that's not what he claimed. It
might be ((void *)0) or something like that, but i very much doubt anyone has
it as ((void *)0xdeadbeef), especially given that NULL _is_ guaranteed to
become 0 when converted to an integer

I didn't say anything about all-bits-zero. NULL usually is something
other than 0 (even if it compares equal to 0), but 0 always works in
initializing a pointer variable, so I thought it should be mentioned
in addition to mentioning NULL.

Also using 0 rather than NULL can be done without having to #include
anything. That's clearly a way that 0 and NULL are different.

 

[Richard Bos]

I could have sworn that there was a guarantee that null pointers
(constant or otherwise) convert to zero

Nope. Constant zeroes convert to null pointers; the other way 'round is
common, but not guaranteed.

how does if(p) work, then? if(p != 0) can be explained by the 0
being converted to a null pointer, and !p is defined as 0==p but i
could have sworn the argument in a conditional had to be an integer
type

You would have perjured yourself. "The controlling expression of an if
statement shall have scalar type" is all the Standard has to say about
it. Well, that, and that the path taken depends on whether said
expression compares equal to 0.

Richard

 

[Default User]

Tim Rentsch wrote:

I didn't say anything about all-bits-zero. NULL usually is something
other than 0 (even if it compares equal to 0), but 0 always works in
initializing a pointer variable, so I thought it should be mentioned
in addition to mentioning NULL.

Do you have some evidence for "usually something other than 0"?



Brian

 

[Tim Rentsch]

Tim Rentsch wrote:




Do you have some evidence for "usually something other than 0"?

Only a personal informal survey. If someone has more extensive
data to report, I'd be interested to hear about (whether it
agrees with mine or not).

 

[Default User]

Only a personal informal survey. If someone has more extensive
data to report, I'd be interested to hear about (whether it
agrees with mine or not).

My two data points are the VC++ 6.0 and gcc 3.3.1 on Solaris, which
both give an all-bits-zero null pointer.

Note that this doesn't have anything to do with the standard language
at all. It's been my impression from previous discussion that some non
0 null pointers exist, but that they were in the minority.



Brian