Thread: what should i use

halo all,
i was just running a simple program.

Code:

#include<stdio.h>
#include<conio.h>
int main(void)
{
        int a[3];
		printf("%u",&a[0]);
			getch();
		return 0;
}

this code runs properly and gives me the address of the first element of the array.but my problem is it also gives me two warnings.

Code:

Warning	1	warning C4313: 'printf' : '%u' in format string conflicts with argument 1 of type 'int *__w64 '		
Warning	2	warning C4996: 'getch' was declared deprecated

why are these two warnings issued. i also tried to change %u to %d but the same warnings were given. i know that i can override these warnings but as i've switched to new compiler i was curious to know about it(my previous compiler didn't show any such warnings).and what should i use in place of %u to remove these errors?
Thanks

It should be:

Code:

printf("%p", (void*)&a[0]);

%p is the format specifier used to print pointers to void.

As for getch(), just read the FAQ and use a standard library near-replacement, or simply run your program from the command line.

Originally Posted by laserlight

It should be:

Code:

printf("%p", (void*)&a[0]);

%p is the format specifier used to print pointers to void.

As for getch(), just read the FAQ and use a standard library near-replacement, or simply run your program from the command line.

1.when i use %p then the address value outputted was changed from what it was with %u or %d.and as u said %p is used to print pointers to void but a is a pointer to an int then is it legal to use %p?
2.how can i run my program from command line?

%p shows a machine specific for of pointer - it is normally in hex form, and often contain the 0x pre-pended. But it may be different, on 16-bit x86, it would print as NNNN:MMMM where N is the segment and M is the offset into the segment, for example.

And if you want to follow the C standard to the letter, only void pointers - this is because void pointers MAY be implemented differently [or rather, OTHER pointers may be implemented differently from a void pointer - as void * should be compatible with ALL pointers, and some machines need a second value to indicate which byte out of a machineword is the source/destination. But they may not need that for ALL pointers - integer or long pointers perhaps don't need this, so why waste the space?].

Edit: in Windows: Window-R, then type in "cmd", then use "cd \my\working\directory" and type in the name of your .exe file.

--
Mats

sorry matsp i didn't understand what u said. I have just started pointers chapter from K&R. So plz tell me in "easy to understand" terms. and also tell me according to C- standards which format specifier should i use to print the address of any variable.

To print a pointer, you should use %p, and you should cast it to void * to ensure that you follow the letter of the standard.

It will MOST likely work on 99 out of 100 machine types without a cast, but would you want to try to figure out what went wrong on the 100th machine type, why it is printing something other than what you expect?

--
Mats

Originally Posted by BEN10

and as u said %p is used to print pointers to void but a is a pointer to an int then is it legal to use %p?

Notice that instead of writing:

Code:

printf("%p", &a[0]);

I cast the pointer to int to a pointer to void:

Code:

printf("%p", (void*)&a[0]);

Originally Posted by BEN10

according to C- standards which format specifier should i use to print the address of any variable.

As I stated in post #2, the %p format specifier should be used.

Originally Posted by matsp

To print a pointer, you should use %p, and you should cast it to void * to ensure that you follow the letter of the standard.

It will MOST likely work on 99 out of 100 machine types without a cast,

--
Mats

ok now i get it that i should use %p for getting the address of the variables. My machine without casting also produces the correct result. is the output shown by %p in hex form?(my system shows output 0012FF58, which is in hex)

Originally Posted by matsp

but would you want to try to figure out what went wrong on the 100th machine type, why it is printing something other than what you expect?
Mats

yes i would definitely like to know what happens in the remaining 1% machines. Why they do not produce correct result without casting?

Code:

    printf("%lu\n", (long unsigned int) main);

try to long specifier

update:
oh, I didn't use -Wall, it need cast

Originally Posted by c.user

Code:

    printf("%lu\n", (long unsigned int) main);

try to long specifier

update:
oh, I didn't use -Wall, it need cast

And it is not at all portable to weird architectures where pointers take up more space than a long for the reasons I explained in the third or so post. Admittedly, those machines are fairly rare, but it's still a valid concern.

Is there any particular reason that printing a variable's address in decimal will make much more sense than printing it in hex? In my experience, addresses are just numbers that have no particular meaning to humans, so whatever representation you use, it's just a sequence of digits (and letters in hex), that can not be used for anything...

--
Mats

Originally Posted by c.user

if you look memory (array of structs, while you are doing a list, example, or something else) the decimal more simple to understand

I can't see why. Some times where hex is useful:

I've seen it make a difference was when you output a pointer (in hex) and get: p = 0xBAADF00D - I saw it in some debugger. I think it was initializing my pointers (that I didn't initialize) to that. Helped catch the bug, but I would've missed it had it not been in hex.

With the advent of 64-bit machines, this will be more convienent. (The decimal form can be much longer...)

Hex can allow you to see memory alignment: If you see 0x04958202, you know it's not aligned on a 4/8/16/4KB+ byte boundry automatically.

Finally, the general convention just seems to be hex. If I see something that's a memory address, I interpret as base-16 first.

Originally Posted by c.user

two forms

Code:

[guest@station src]$ ./test
 3218598376 3218598380 3218598384 3218598388 3218598392
   bfd7e9e8   bfd7e9ec   bfd7e9f0   bfd7e9f4   bfd7e9f8
[guest@station src]$

it is addresses of one int array (if there are big spaces between elements it is easy to count it because there are no letters)

ya. I agree with you as it is easier to count the difference between element addresses when using decimal form. And from it, it is also easier to tell us how much byte an int or any data type is occupying.
But on the other hand (as i'm also doing my microprocessors course) every address is written in the form of Hex.

Small differences in hex aren't that difficult - but of course, decimal 24-16 is easier than 0x18 - 0x10, right?. Big (non-obvious) differences, I usually end up using a calculator whether it is hex or decimal.

--
Mats