Clarification on various format specifiers in C program
I am not understanding what is major difference between %p
,%u
,%x
,%d
, except that %x
shows hexadecimal,%u
is used for unsigned integer and that %d
is for any integer. I am very much confused after I took a integer variable and printed its address and its value (positive integer) separately, then irrespective of whatever format specifier I use, it was correctly printing the output (except of the difference in hexadecimal and decimal number system). So what is a major difference?
And if there is not much difference then which format specifiers are preferable for printing what type of variables?
Another doubt is that: Whether pointer of all multiplicity (I mean int *p;
int **p;
int ***p;
etc.) occupy the same size (which is the size needed to store a valid address in the machine)? If not, then what is the size of these pointers?
Thanks for your help.
c size format-specifiers
|
show 2 more comments
I am not understanding what is major difference between %p
,%u
,%x
,%d
, except that %x
shows hexadecimal,%u
is used for unsigned integer and that %d
is for any integer. I am very much confused after I took a integer variable and printed its address and its value (positive integer) separately, then irrespective of whatever format specifier I use, it was correctly printing the output (except of the difference in hexadecimal and decimal number system). So what is a major difference?
And if there is not much difference then which format specifiers are preferable for printing what type of variables?
Another doubt is that: Whether pointer of all multiplicity (I mean int *p;
int **p;
int ***p;
etc.) occupy the same size (which is the size needed to store a valid address in the machine)? If not, then what is the size of these pointers?
Thanks for your help.
c size format-specifiers
1
Please go through the table at printf, fprintf, sprintf, snprintf, printf_s, fprintf_s, sprintf_s, snprintf_s which describes all conversion specifications in detail.
– Swordfish
Nov 13 '18 at 13:21
Actually @pmg the size of a pointer is alwayssizeof(char/int/... *)
because the pointer is a variable type. Settingchar
orint
will just tell the computer that the step is onechar
or oneint
long.
– Jean-Marc Zimmer
Nov 13 '18 at 13:23
Yes, those pointers all occupy the same size. However, this size depends on the platform and the hardware.
– Motun
Nov 13 '18 at 13:24
@Jean-MarcZimmer: The C standard does not require pointers of different types to be the same size.
– Eric Postpischil
Nov 13 '18 at 13:28
1
@Motun: in practice, pointers to data types will likely occupy the same platform-dependent size, but this is not mandated by the standard and shouldn't be considered portable. It's more common for pointers to functions to occupy a different platform-dependent size than data pointers, and you should never cast between data pointers and function pointers (nor cast fromvoid*
to a function pointer).
– Groo
Nov 13 '18 at 13:30
|
show 2 more comments
I am not understanding what is major difference between %p
,%u
,%x
,%d
, except that %x
shows hexadecimal,%u
is used for unsigned integer and that %d
is for any integer. I am very much confused after I took a integer variable and printed its address and its value (positive integer) separately, then irrespective of whatever format specifier I use, it was correctly printing the output (except of the difference in hexadecimal and decimal number system). So what is a major difference?
And if there is not much difference then which format specifiers are preferable for printing what type of variables?
Another doubt is that: Whether pointer of all multiplicity (I mean int *p;
int **p;
int ***p;
etc.) occupy the same size (which is the size needed to store a valid address in the machine)? If not, then what is the size of these pointers?
Thanks for your help.
c size format-specifiers
I am not understanding what is major difference between %p
,%u
,%x
,%d
, except that %x
shows hexadecimal,%u
is used for unsigned integer and that %d
is for any integer. I am very much confused after I took a integer variable and printed its address and its value (positive integer) separately, then irrespective of whatever format specifier I use, it was correctly printing the output (except of the difference in hexadecimal and decimal number system). So what is a major difference?
And if there is not much difference then which format specifiers are preferable for printing what type of variables?
Another doubt is that: Whether pointer of all multiplicity (I mean int *p;
int **p;
int ***p;
etc.) occupy the same size (which is the size needed to store a valid address in the machine)? If not, then what is the size of these pointers?
Thanks for your help.
c size format-specifiers
c size format-specifiers
edited Nov 13 '18 at 13:33
Sander De Dycker
12.5k12331
12.5k12331
asked Nov 13 '18 at 13:15
MartundMartund
1011
1011
1
Please go through the table at printf, fprintf, sprintf, snprintf, printf_s, fprintf_s, sprintf_s, snprintf_s which describes all conversion specifications in detail.
– Swordfish
Nov 13 '18 at 13:21
Actually @pmg the size of a pointer is alwayssizeof(char/int/... *)
because the pointer is a variable type. Settingchar
orint
will just tell the computer that the step is onechar
or oneint
long.
– Jean-Marc Zimmer
Nov 13 '18 at 13:23
Yes, those pointers all occupy the same size. However, this size depends on the platform and the hardware.
– Motun
Nov 13 '18 at 13:24
@Jean-MarcZimmer: The C standard does not require pointers of different types to be the same size.
– Eric Postpischil
Nov 13 '18 at 13:28
1
@Motun: in practice, pointers to data types will likely occupy the same platform-dependent size, but this is not mandated by the standard and shouldn't be considered portable. It's more common for pointers to functions to occupy a different platform-dependent size than data pointers, and you should never cast between data pointers and function pointers (nor cast fromvoid*
to a function pointer).
– Groo
Nov 13 '18 at 13:30
|
show 2 more comments
1
Please go through the table at printf, fprintf, sprintf, snprintf, printf_s, fprintf_s, sprintf_s, snprintf_s which describes all conversion specifications in detail.
– Swordfish
Nov 13 '18 at 13:21
Actually @pmg the size of a pointer is alwayssizeof(char/int/... *)
because the pointer is a variable type. Settingchar
orint
will just tell the computer that the step is onechar
or oneint
long.
– Jean-Marc Zimmer
Nov 13 '18 at 13:23
Yes, those pointers all occupy the same size. However, this size depends on the platform and the hardware.
– Motun
Nov 13 '18 at 13:24
@Jean-MarcZimmer: The C standard does not require pointers of different types to be the same size.
– Eric Postpischil
Nov 13 '18 at 13:28
1
@Motun: in practice, pointers to data types will likely occupy the same platform-dependent size, but this is not mandated by the standard and shouldn't be considered portable. It's more common for pointers to functions to occupy a different platform-dependent size than data pointers, and you should never cast between data pointers and function pointers (nor cast fromvoid*
to a function pointer).
– Groo
Nov 13 '18 at 13:30
1
1
Please go through the table at printf, fprintf, sprintf, snprintf, printf_s, fprintf_s, sprintf_s, snprintf_s which describes all conversion specifications in detail.
– Swordfish
Nov 13 '18 at 13:21
Please go through the table at printf, fprintf, sprintf, snprintf, printf_s, fprintf_s, sprintf_s, snprintf_s which describes all conversion specifications in detail.
– Swordfish
Nov 13 '18 at 13:21
Actually @pmg the size of a pointer is always
sizeof(char/int/... *)
because the pointer is a variable type. Setting char
or int
will just tell the computer that the step is one char
or one int
long.– Jean-Marc Zimmer
Nov 13 '18 at 13:23
Actually @pmg the size of a pointer is always
sizeof(char/int/... *)
because the pointer is a variable type. Setting char
or int
will just tell the computer that the step is one char
or one int
long.– Jean-Marc Zimmer
Nov 13 '18 at 13:23
Yes, those pointers all occupy the same size. However, this size depends on the platform and the hardware.
– Motun
Nov 13 '18 at 13:24
Yes, those pointers all occupy the same size. However, this size depends on the platform and the hardware.
– Motun
Nov 13 '18 at 13:24
@Jean-MarcZimmer: The C standard does not require pointers of different types to be the same size.
– Eric Postpischil
Nov 13 '18 at 13:28
@Jean-MarcZimmer: The C standard does not require pointers of different types to be the same size.
– Eric Postpischil
Nov 13 '18 at 13:28
1
1
@Motun: in practice, pointers to data types will likely occupy the same platform-dependent size, but this is not mandated by the standard and shouldn't be considered portable. It's more common for pointers to functions to occupy a different platform-dependent size than data pointers, and you should never cast between data pointers and function pointers (nor cast from
void*
to a function pointer).– Groo
Nov 13 '18 at 13:30
@Motun: in practice, pointers to data types will likely occupy the same platform-dependent size, but this is not mandated by the standard and shouldn't be considered portable. It's more common for pointers to functions to occupy a different platform-dependent size than data pointers, and you should never cast between data pointers and function pointers (nor cast from
void*
to a function pointer).– Groo
Nov 13 '18 at 13:30
|
show 2 more comments
2 Answers
2
active
oldest
votes
The %u
, %x
, %d
, and %p
format specifiers are used as follows:
%u
: expects anunsigned int
as a parameter and prints it in decimal format.
%x
: expects anunsigned int
as a parameter and prints it in hexadecimal format.
%d
: expects anint
as a parameter and prints it in decimal format.
%p
: expects avoid *
as a parameter and prints it in an implementation defined way (typically as a hexadecimal number)
Additionally, %u
, %x
, %d
can be prefixed with a length modifier:
l
: denotes along int
orunsigned long int
ll
: denotes along long int
orunsigned long long int
h
: denotes ashort int
orunsigned short int
hh
: denotes asigned char
orunsigned char
Regarding pointer sizes, int *
, int **
, int ***
, etc. are not required to be the same size, although on most implementations they will be.
In[type] variable = malloc(the_size_you_want);
: when you usechar *
you define a pointer which has a step the size of achar
. If you useint *
, the same, but with a step of an int. Withchar **
orint **
, you define your pointer with a step the size of the corresponding pointer, but the inside variables are not initialized.
– Jean-Marc Zimmer
Nov 13 '18 at 13:29
In which cases are the sizes of int*,int**,int***,etc. different?
– Martund
Nov 13 '18 at 13:48
@Crazyformaths I'm not aware of an implementation where they are different, however the C standard does not require them to be the same size so it's best not to assume they are.
– dbush
Nov 13 '18 at 13:53
1
@Crazyformaths Each of those cases invokes undefined behavior because the type of the parameter doesn't match the the format specifier. Just because it appears to work doesn't mean it's valid.
– dbush
Nov 13 '18 at 13:59
1
On your implementation, pointers might be represented as simple integers in which case you'd get consistent results. However, if you were to run the same code on a different system those statements might print different things. One of the consequences of undefined behavior is that things may appear to "work".
– dbush
Nov 13 '18 at 14:07
|
show 3 more comments
With format specifiers, you tell the computer how to interpret the given variable/data.
A quick demo:
#include <stdio.h>
int main(void)
{
int x = -5;
printf("x value as int: [%d]n", x);
printf("x value as unsigned int: [%u]n", x);
printf("x value as hexadecimal: [%x]n", x);
printf("x value as pointer: [%p]n", x);
return 0;
}
Output:
x value as int: [-5]
x value as unsigned int: [4294967291]
x value as hexadecimal: [fffffffb]
x value as pointer: [0xfffffffb]
It's the same value given every time, i.e. x = -5
.
We see the exact representation when given the right format specifier (the first case).
In second case we see a very big number. The answer to "Why" is a bit long to explain here, but you should look up how negative integers are represented in 2's complement system.
In the third case we see the hexadecimal representation of the number
4294967291
. Hexadecimal numbers are usually shown with0x
at the beginning but%x
doesn't do that.The last one just shows how would the variable
x
seem if it were an address in the memory, again in hexadecimal format of course.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53281845%2fclarification-on-various-format-specifiers-in-c-program%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The %u
, %x
, %d
, and %p
format specifiers are used as follows:
%u
: expects anunsigned int
as a parameter and prints it in decimal format.
%x
: expects anunsigned int
as a parameter and prints it in hexadecimal format.
%d
: expects anint
as a parameter and prints it in decimal format.
%p
: expects avoid *
as a parameter and prints it in an implementation defined way (typically as a hexadecimal number)
Additionally, %u
, %x
, %d
can be prefixed with a length modifier:
l
: denotes along int
orunsigned long int
ll
: denotes along long int
orunsigned long long int
h
: denotes ashort int
orunsigned short int
hh
: denotes asigned char
orunsigned char
Regarding pointer sizes, int *
, int **
, int ***
, etc. are not required to be the same size, although on most implementations they will be.
In[type] variable = malloc(the_size_you_want);
: when you usechar *
you define a pointer which has a step the size of achar
. If you useint *
, the same, but with a step of an int. Withchar **
orint **
, you define your pointer with a step the size of the corresponding pointer, but the inside variables are not initialized.
– Jean-Marc Zimmer
Nov 13 '18 at 13:29
In which cases are the sizes of int*,int**,int***,etc. different?
– Martund
Nov 13 '18 at 13:48
@Crazyformaths I'm not aware of an implementation where they are different, however the C standard does not require them to be the same size so it's best not to assume they are.
– dbush
Nov 13 '18 at 13:53
1
@Crazyformaths Each of those cases invokes undefined behavior because the type of the parameter doesn't match the the format specifier. Just because it appears to work doesn't mean it's valid.
– dbush
Nov 13 '18 at 13:59
1
On your implementation, pointers might be represented as simple integers in which case you'd get consistent results. However, if you were to run the same code on a different system those statements might print different things. One of the consequences of undefined behavior is that things may appear to "work".
– dbush
Nov 13 '18 at 14:07
|
show 3 more comments
The %u
, %x
, %d
, and %p
format specifiers are used as follows:
%u
: expects anunsigned int
as a parameter and prints it in decimal format.
%x
: expects anunsigned int
as a parameter and prints it in hexadecimal format.
%d
: expects anint
as a parameter and prints it in decimal format.
%p
: expects avoid *
as a parameter and prints it in an implementation defined way (typically as a hexadecimal number)
Additionally, %u
, %x
, %d
can be prefixed with a length modifier:
l
: denotes along int
orunsigned long int
ll
: denotes along long int
orunsigned long long int
h
: denotes ashort int
orunsigned short int
hh
: denotes asigned char
orunsigned char
Regarding pointer sizes, int *
, int **
, int ***
, etc. are not required to be the same size, although on most implementations they will be.
In[type] variable = malloc(the_size_you_want);
: when you usechar *
you define a pointer which has a step the size of achar
. If you useint *
, the same, but with a step of an int. Withchar **
orint **
, you define your pointer with a step the size of the corresponding pointer, but the inside variables are not initialized.
– Jean-Marc Zimmer
Nov 13 '18 at 13:29
In which cases are the sizes of int*,int**,int***,etc. different?
– Martund
Nov 13 '18 at 13:48
@Crazyformaths I'm not aware of an implementation where they are different, however the C standard does not require them to be the same size so it's best not to assume they are.
– dbush
Nov 13 '18 at 13:53
1
@Crazyformaths Each of those cases invokes undefined behavior because the type of the parameter doesn't match the the format specifier. Just because it appears to work doesn't mean it's valid.
– dbush
Nov 13 '18 at 13:59
1
On your implementation, pointers might be represented as simple integers in which case you'd get consistent results. However, if you were to run the same code on a different system those statements might print different things. One of the consequences of undefined behavior is that things may appear to "work".
– dbush
Nov 13 '18 at 14:07
|
show 3 more comments
The %u
, %x
, %d
, and %p
format specifiers are used as follows:
%u
: expects anunsigned int
as a parameter and prints it in decimal format.
%x
: expects anunsigned int
as a parameter and prints it in hexadecimal format.
%d
: expects anint
as a parameter and prints it in decimal format.
%p
: expects avoid *
as a parameter and prints it in an implementation defined way (typically as a hexadecimal number)
Additionally, %u
, %x
, %d
can be prefixed with a length modifier:
l
: denotes along int
orunsigned long int
ll
: denotes along long int
orunsigned long long int
h
: denotes ashort int
orunsigned short int
hh
: denotes asigned char
orunsigned char
Regarding pointer sizes, int *
, int **
, int ***
, etc. are not required to be the same size, although on most implementations they will be.
The %u
, %x
, %d
, and %p
format specifiers are used as follows:
%u
: expects anunsigned int
as a parameter and prints it in decimal format.
%x
: expects anunsigned int
as a parameter and prints it in hexadecimal format.
%d
: expects anint
as a parameter and prints it in decimal format.
%p
: expects avoid *
as a parameter and prints it in an implementation defined way (typically as a hexadecimal number)
Additionally, %u
, %x
, %d
can be prefixed with a length modifier:
l
: denotes along int
orunsigned long int
ll
: denotes along long int
orunsigned long long int
h
: denotes ashort int
orunsigned short int
hh
: denotes asigned char
orunsigned char
Regarding pointer sizes, int *
, int **
, int ***
, etc. are not required to be the same size, although on most implementations they will be.
answered Nov 13 '18 at 13:23
dbushdbush
94.7k12101136
94.7k12101136
In[type] variable = malloc(the_size_you_want);
: when you usechar *
you define a pointer which has a step the size of achar
. If you useint *
, the same, but with a step of an int. Withchar **
orint **
, you define your pointer with a step the size of the corresponding pointer, but the inside variables are not initialized.
– Jean-Marc Zimmer
Nov 13 '18 at 13:29
In which cases are the sizes of int*,int**,int***,etc. different?
– Martund
Nov 13 '18 at 13:48
@Crazyformaths I'm not aware of an implementation where they are different, however the C standard does not require them to be the same size so it's best not to assume they are.
– dbush
Nov 13 '18 at 13:53
1
@Crazyformaths Each of those cases invokes undefined behavior because the type of the parameter doesn't match the the format specifier. Just because it appears to work doesn't mean it's valid.
– dbush
Nov 13 '18 at 13:59
1
On your implementation, pointers might be represented as simple integers in which case you'd get consistent results. However, if you were to run the same code on a different system those statements might print different things. One of the consequences of undefined behavior is that things may appear to "work".
– dbush
Nov 13 '18 at 14:07
|
show 3 more comments
In[type] variable = malloc(the_size_you_want);
: when you usechar *
you define a pointer which has a step the size of achar
. If you useint *
, the same, but with a step of an int. Withchar **
orint **
, you define your pointer with a step the size of the corresponding pointer, but the inside variables are not initialized.
– Jean-Marc Zimmer
Nov 13 '18 at 13:29
In which cases are the sizes of int*,int**,int***,etc. different?
– Martund
Nov 13 '18 at 13:48
@Crazyformaths I'm not aware of an implementation where they are different, however the C standard does not require them to be the same size so it's best not to assume they are.
– dbush
Nov 13 '18 at 13:53
1
@Crazyformaths Each of those cases invokes undefined behavior because the type of the parameter doesn't match the the format specifier. Just because it appears to work doesn't mean it's valid.
– dbush
Nov 13 '18 at 13:59
1
On your implementation, pointers might be represented as simple integers in which case you'd get consistent results. However, if you were to run the same code on a different system those statements might print different things. One of the consequences of undefined behavior is that things may appear to "work".
– dbush
Nov 13 '18 at 14:07
In
[type] variable = malloc(the_size_you_want);
: when you use char *
you define a pointer which has a step the size of a char
. If you use int *
, the same, but with a step of an int. With char **
or int **
, you define your pointer with a step the size of the corresponding pointer, but the inside variables are not initialized.– Jean-Marc Zimmer
Nov 13 '18 at 13:29
In
[type] variable = malloc(the_size_you_want);
: when you use char *
you define a pointer which has a step the size of a char
. If you use int *
, the same, but with a step of an int. With char **
or int **
, you define your pointer with a step the size of the corresponding pointer, but the inside variables are not initialized.– Jean-Marc Zimmer
Nov 13 '18 at 13:29
In which cases are the sizes of int*,int**,int***,etc. different?
– Martund
Nov 13 '18 at 13:48
In which cases are the sizes of int*,int**,int***,etc. different?
– Martund
Nov 13 '18 at 13:48
@Crazyformaths I'm not aware of an implementation where they are different, however the C standard does not require them to be the same size so it's best not to assume they are.
– dbush
Nov 13 '18 at 13:53
@Crazyformaths I'm not aware of an implementation where they are different, however the C standard does not require them to be the same size so it's best not to assume they are.
– dbush
Nov 13 '18 at 13:53
1
1
@Crazyformaths Each of those cases invokes undefined behavior because the type of the parameter doesn't match the the format specifier. Just because it appears to work doesn't mean it's valid.
– dbush
Nov 13 '18 at 13:59
@Crazyformaths Each of those cases invokes undefined behavior because the type of the parameter doesn't match the the format specifier. Just because it appears to work doesn't mean it's valid.
– dbush
Nov 13 '18 at 13:59
1
1
On your implementation, pointers might be represented as simple integers in which case you'd get consistent results. However, if you were to run the same code on a different system those statements might print different things. One of the consequences of undefined behavior is that things may appear to "work".
– dbush
Nov 13 '18 at 14:07
On your implementation, pointers might be represented as simple integers in which case you'd get consistent results. However, if you were to run the same code on a different system those statements might print different things. One of the consequences of undefined behavior is that things may appear to "work".
– dbush
Nov 13 '18 at 14:07
|
show 3 more comments
With format specifiers, you tell the computer how to interpret the given variable/data.
A quick demo:
#include <stdio.h>
int main(void)
{
int x = -5;
printf("x value as int: [%d]n", x);
printf("x value as unsigned int: [%u]n", x);
printf("x value as hexadecimal: [%x]n", x);
printf("x value as pointer: [%p]n", x);
return 0;
}
Output:
x value as int: [-5]
x value as unsigned int: [4294967291]
x value as hexadecimal: [fffffffb]
x value as pointer: [0xfffffffb]
It's the same value given every time, i.e. x = -5
.
We see the exact representation when given the right format specifier (the first case).
In second case we see a very big number. The answer to "Why" is a bit long to explain here, but you should look up how negative integers are represented in 2's complement system.
In the third case we see the hexadecimal representation of the number
4294967291
. Hexadecimal numbers are usually shown with0x
at the beginning but%x
doesn't do that.The last one just shows how would the variable
x
seem if it were an address in the memory, again in hexadecimal format of course.
add a comment |
With format specifiers, you tell the computer how to interpret the given variable/data.
A quick demo:
#include <stdio.h>
int main(void)
{
int x = -5;
printf("x value as int: [%d]n", x);
printf("x value as unsigned int: [%u]n", x);
printf("x value as hexadecimal: [%x]n", x);
printf("x value as pointer: [%p]n", x);
return 0;
}
Output:
x value as int: [-5]
x value as unsigned int: [4294967291]
x value as hexadecimal: [fffffffb]
x value as pointer: [0xfffffffb]
It's the same value given every time, i.e. x = -5
.
We see the exact representation when given the right format specifier (the first case).
In second case we see a very big number. The answer to "Why" is a bit long to explain here, but you should look up how negative integers are represented in 2's complement system.
In the third case we see the hexadecimal representation of the number
4294967291
. Hexadecimal numbers are usually shown with0x
at the beginning but%x
doesn't do that.The last one just shows how would the variable
x
seem if it were an address in the memory, again in hexadecimal format of course.
add a comment |
With format specifiers, you tell the computer how to interpret the given variable/data.
A quick demo:
#include <stdio.h>
int main(void)
{
int x = -5;
printf("x value as int: [%d]n", x);
printf("x value as unsigned int: [%u]n", x);
printf("x value as hexadecimal: [%x]n", x);
printf("x value as pointer: [%p]n", x);
return 0;
}
Output:
x value as int: [-5]
x value as unsigned int: [4294967291]
x value as hexadecimal: [fffffffb]
x value as pointer: [0xfffffffb]
It's the same value given every time, i.e. x = -5
.
We see the exact representation when given the right format specifier (the first case).
In second case we see a very big number. The answer to "Why" is a bit long to explain here, but you should look up how negative integers are represented in 2's complement system.
In the third case we see the hexadecimal representation of the number
4294967291
. Hexadecimal numbers are usually shown with0x
at the beginning but%x
doesn't do that.The last one just shows how would the variable
x
seem if it were an address in the memory, again in hexadecimal format of course.
With format specifiers, you tell the computer how to interpret the given variable/data.
A quick demo:
#include <stdio.h>
int main(void)
{
int x = -5;
printf("x value as int: [%d]n", x);
printf("x value as unsigned int: [%u]n", x);
printf("x value as hexadecimal: [%x]n", x);
printf("x value as pointer: [%p]n", x);
return 0;
}
Output:
x value as int: [-5]
x value as unsigned int: [4294967291]
x value as hexadecimal: [fffffffb]
x value as pointer: [0xfffffffb]
It's the same value given every time, i.e. x = -5
.
We see the exact representation when given the right format specifier (the first case).
In second case we see a very big number. The answer to "Why" is a bit long to explain here, but you should look up how negative integers are represented in 2's complement system.
In the third case we see the hexadecimal representation of the number
4294967291
. Hexadecimal numbers are usually shown with0x
at the beginning but%x
doesn't do that.The last one just shows how would the variable
x
seem if it were an address in the memory, again in hexadecimal format of course.
answered Nov 13 '18 at 13:38
MotunMotun
1,15131219
1,15131219
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53281845%2fclarification-on-various-format-specifiers-in-c-program%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Please go through the table at printf, fprintf, sprintf, snprintf, printf_s, fprintf_s, sprintf_s, snprintf_s which describes all conversion specifications in detail.
– Swordfish
Nov 13 '18 at 13:21
Actually @pmg the size of a pointer is always
sizeof(char/int/... *)
because the pointer is a variable type. Settingchar
orint
will just tell the computer that the step is onechar
or oneint
long.– Jean-Marc Zimmer
Nov 13 '18 at 13:23
Yes, those pointers all occupy the same size. However, this size depends on the platform and the hardware.
– Motun
Nov 13 '18 at 13:24
@Jean-MarcZimmer: The C standard does not require pointers of different types to be the same size.
– Eric Postpischil
Nov 13 '18 at 13:28
1
@Motun: in practice, pointers to data types will likely occupy the same platform-dependent size, but this is not mandated by the standard and shouldn't be considered portable. It's more common for pointers to functions to occupy a different platform-dependent size than data pointers, and you should never cast between data pointers and function pointers (nor cast from
void*
to a function pointer).– Groo
Nov 13 '18 at 13:30