Maximum characters printable by printf in C
In C's printf function in using this gigantic string formatter width sub-specifier; close to the standard's limit a positive signed int; which is provided below the rest of the string formats are ignored.
Example String format:
printf("**%2147483614p %1073739618p This text and %d formatters are ignored!!! why**", &i, &j, 10);
output:
**2147483614 empty spaces0xbf****** 1073739618 empty spaces
Problem:
The text "**This text and 10 formatters are ignored!!! why****" and the integer 10 does not show up on screen.
It prints the full of the first %p with its padding and the padding created by the width specifier for the second %p but no pointer and rest of string to be printed.
Note: the second pointer can be made to be printed by left adjusting the format specifier like
printf("%-2147483614p %-1073739618p This text and %d formatters are ignored!!! why**", &i, &j, 10);**
but still the strings after are still missing.
The code
#include <stdio.h>
int main(int argc, char const *argv){
printf(argv[1]);
return 0;
}
x86_64-linux-gnu
gcc version 7.3.0
gcc printf.c -o printf
./printf "%-2147483614p %-1073739618p This text and %d formatters are ignored!!! why"
P.S. I am aware this is a memory leak
Found out %29p (29 is the max, 30 would not print) for second pointer prints the rest of the string. but if there is another format sting in the rest of the string it stops there.
c string printf string-formatting
asked Nov 21 '18 at 20:14
Eyosias NegashEyosias Negash
223
|
show 6 more comments
In C's printf function in using this gigantic string formatter width sub-specifier; close to the standard's limit a positive signed int; which is provided below the rest of the string formats are ignored.
Example String format:
printf("**%2147483614p %1073739618p This text and %d formatters are ignored!!! why**", &i, &j, 10);
output:
**2147483614 empty spaces0xbf****** 1073739618 empty spaces
Problem:
The text "**This text and 10 formatters are ignored!!! why****" and the integer 10 does not show up on screen.
It prints the full of the first %p with its padding and the padding created by the width specifier for the second %p but no pointer and rest of string to be printed.
Note: the second pointer can be made to be printed by left adjusting the format specifier like
printf("%-2147483614p %-1073739618p This text and %d formatters are ignored!!! why**", &i, &j, 10);**
but still the strings after are still missing.
The code
#include <stdio.h>
int main(int argc, char const *argv){
printf(argv[1]);
return 0;
}
x86_64-linux-gnu
gcc version 7.3.0
gcc printf.c -o printf
./printf "%-2147483614p %-1073739618p This text and %d formatters are ignored!!! why"
P.S. I am aware this is a memory leak
Found out %29p (29 is the max, 30 would not print) for second pointer prints the rest of the string. but if there is another format sting in the rest of the string it stops there.
c string printf string-formatting
asked Nov 21 '18 at 20:14
Eyosias NegashEyosias Negash
223
3
0x7ffffffeis most likely notINT_MAX.
– Osiris
Nov 21 '18 at 20:17
6
Please include a MCVE that shows the problem . The exact code you used is important
– M.M
Nov 21 '18 at 20:19
INT_MAX is probably0x7fffffffon compiler with 32 bt integers
– Jean-François Fabre
Nov 21 '18 at 20:19
1
In addition to the code for the MVCE @M.M asks for you should indicate what platform you're running the test on and the compiler toolchain you're using.
– Michael Burr
Nov 21 '18 at 20:29
1
Are you asking specifically about the width value provided to a print format conversion specifier?
– jxh
Nov 21 '18 at 20:36
|
show 6 more comments
In C's printf function in using this gigantic string formatter width sub-specifier; close to the standard's limit a positive signed int; which is provided below the rest of the string formats are ignored.
Example String format:
printf("**%2147483614p %1073739618p This text and %d formatters are ignored!!! why**", &i, &j, 10);
output:
**2147483614 empty spaces0xbf****** 1073739618 empty spaces
Problem:
The text "**This text and 10 formatters are ignored!!! why****" and the integer 10 does not show up on screen.
It prints the full of the first %p with its padding and the padding created by the width specifier for the second %p but no pointer and rest of string to be printed.
Note: the second pointer can be made to be printed by left adjusting the format specifier like
printf("%-2147483614p %-1073739618p This text and %d formatters are ignored!!! why**", &i, &j, 10);**
but still the strings after are still missing.
The code
#include <stdio.h>
int main(int argc, char const *argv){
printf(argv[1]);
return 0;
}
x86_64-linux-gnu
gcc version 7.3.0
gcc printf.c -o printf
./printf "%-2147483614p %-1073739618p This text and %d formatters are ignored!!! why"
P.S. I am aware this is a memory leak
Found out %29p (29 is the max, 30 would not print) for second pointer prints the rest of the string. but if there is another format sting in the rest of the string it stops there.
c string printf string-formatting
asked Nov 21 '18 at 20:14
Eyosias NegashEyosias Negash
223
In C's printf function in using this gigantic string formatter width sub-specifier; close to the standard's limit a positive signed int; which is provided below the rest of the string formats are ignored.
Example String format:
printf("**%2147483614p %1073739618p This text and %d formatters are ignored!!! why**", &i, &j, 10);
output:
**2147483614 empty spaces0xbf****** 1073739618 empty spaces
Problem:
The text "**This text and 10 formatters are ignored!!! why****" and the integer 10 does not show up on screen.
It prints the full of the first %p with its padding and the padding created by the width specifier for the second %p but no pointer and rest of string to be printed.
Note: the second pointer can be made to be printed by left adjusting the format specifier like
printf("%-2147483614p %-1073739618p This text and %d formatters are ignored!!! why**", &i, &j, 10);**
but still the strings after are still missing.
The code
#include <stdio.h>
int main(int argc, char const *argv){
printf(argv[1]);
return 0;
}
x86_64-linux-gnu
gcc version 7.3.0
gcc printf.c -o printf
./printf "%-2147483614p %-1073739618p This text and %d formatters are ignored!!! why"
P.S. I am aware this is a memory leak
Found out %29p (29 is the max, 30 would not print) for second pointer prints the rest of the string. but if there is another format sting in the rest of the string it stops there.
c string printf string-formatting
c string printf string-formatting
asked Nov 21 '18 at 20:14
Eyosias NegashEyosias Negash
223
asked Nov 21 '18 at 20:14
Eyosias NegashEyosias Negash
223
edited Nov 21 '18 at 23:15
Eyosias Negash
asked Nov 21 '18 at 20:14
Eyosias NegashEyosias Negash
223
asked Nov 21 '18 at 20:14
Eyosias NegashEyosias Negash
223
asked Nov 21 '18 at 20:14
Eyosias NegashEyosias Negash
223
223
3
0x7ffffffeis most likely notINT_MAX.
– Osiris
Nov 21 '18 at 20:17
6
Please include a MCVE that shows the problem . The exact code you used is important
– M.M
Nov 21 '18 at 20:19
INT_MAX is probably0x7fffffffon compiler with 32 bt integers
– Jean-François Fabre
Nov 21 '18 at 20:19
1
In addition to the code for the MVCE @M.M asks for you should indicate what platform you're running the test on and the compiler toolchain you're using.
– Michael Burr
Nov 21 '18 at 20:29
1
Are you asking specifically about the width value provided to a print format conversion specifier?
– jxh
Nov 21 '18 at 20:36
|
show 6 more comments
3
0x7ffffffeis most likely notINT_MAX.
– Osiris
Nov 21 '18 at 20:17
6
Please include a MCVE that shows the problem . The exact code you used is important
– M.M
Nov 21 '18 at 20:19
INT_MAX is probably0x7fffffffon compiler with 32 bt integers
– Jean-François Fabre
Nov 21 '18 at 20:19
1
In addition to the code for the MVCE @M.M asks for you should indicate what platform you're running the test on and the compiler toolchain you're using.
– Michael Burr
Nov 21 '18 at 20:29
1
Are you asking specifically about the width value provided to a print format conversion specifier?
– jxh
Nov 21 '18 at 20:36
3
3
0x7ffffffe is most likely not INT_MAX.– Osiris
Nov 21 '18 at 20:17
0x7ffffffe is most likely not INT_MAX.– Osiris
Nov 21 '18 at 20:17
6
6
Please include a MCVE that shows the problem . The exact code you used is important
– M.M
Nov 21 '18 at 20:19
Please include a MCVE that shows the problem . The exact code you used is important
– M.M
Nov 21 '18 at 20:19
INT_MAX is probably
0x7fffffff on compiler with 32 bt integers– Jean-François Fabre
Nov 21 '18 at 20:19
INT_MAX is probably
0x7fffffff on compiler with 32 bt integers– Jean-François Fabre
Nov 21 '18 at 20:19
1
1
In addition to the code for the MVCE @M.M asks for you should indicate what platform you're running the test on and the compiler toolchain you're using.
– Michael Burr
Nov 21 '18 at 20:29
In addition to the code for the MVCE @M.M asks for you should indicate what platform you're running the test on and the compiler toolchain you're using.
– Michael Burr
Nov 21 '18 at 20:29
1
1
Are you asking specifically about the width value provided to a print format conversion specifier?
– jxh
Nov 21 '18 at 20:36
Are you asking specifically about the width value provided to a print format conversion specifier?
– jxh
Nov 21 '18 at 20:36
|
show 6 more comments
1 Answer
1
active
oldest
votes
If you are asking specifically about the maximum width specifier, according to the C Standard, §7.21.6.1.15 (which describes fprintf; printf is described later as a specific case of fprintf):
The number of characters that can be produced by any single conversion shall be at least
4095.
This means that if, as you report, the maximum width that your C implementation's printf can handle for a format specifier before it stops working as expected is 0x7fffffe2, this is acceptable, since that satisfies the requirement of at least 4095 characters.
As for the remainder of the string not being printed out, without an MCVE, I would hazard a guess at it being a side effect of having such nonsensical width values earlier in the string. Also, %D is not a valid format specifier.
answered Nov 21 '18 at 20:44
Govind ParmarGovind Parmar
7,15553055
@M.M How exactly does the paragraph after the quote contradict anything discussed about environmental limits in the standard?
– Govind Parmar
Nov 21 '18 at 21:16
1
@M.M Really? To me it's just a restatement of the accepted answer here: stackoverflow.com/questions/27800706/… (i.e. that implementations must support at least that much, but can support more, and in OP's case, it's 0x7fffffe2)
– Govind Parmar
Nov 21 '18 at 21:25
From your quote of the standard, I would expect"%4095p"to print out the value of the pointer padded out to 4095 bytes. Your statement you are not guaranteed that anything else will get converted for that format specifier seems to imply the pointer value might not get printed.
– jxh
Nov 21 '18 at 21:31
@jxh Reworded my answer, particularly the paragraph after the standard quote
– Govind Parmar
Nov 21 '18 at 21:36
1
@M.M What is a conforming implementation to do with a program that attempts to emit more than the environmental limits allow?
– jxh
Nov 21 '18 at 23:54
|
show 5 more comments
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%2f53419825%2fmaximum-characters-printable-by-printf-in-c%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
If you are asking specifically about the maximum width specifier, according to the C Standard, §7.21.6.1.15 (which describes fprintf; printf is described later as a specific case of fprintf):
The number of characters that can be produced by any single conversion shall be at least
4095.
This means that if, as you report, the maximum width that your C implementation's printf can handle for a format specifier before it stops working as expected is 0x7fffffe2, this is acceptable, since that satisfies the requirement of at least 4095 characters.
As for the remainder of the string not being printed out, without an MCVE, I would hazard a guess at it being a side effect of having such nonsensical width values earlier in the string. Also, %D is not a valid format specifier.
answered Nov 21 '18 at 20:44
Govind ParmarGovind Parmar
7,15553055
@M.M How exactly does the paragraph after the quote contradict anything discussed about environmental limits in the standard?
– Govind Parmar
Nov 21 '18 at 21:16
1
@M.M Really? To me it's just a restatement of the accepted answer here: stackoverflow.com/questions/27800706/… (i.e. that implementations must support at least that much, but can support more, and in OP's case, it's 0x7fffffe2)
– Govind Parmar
Nov 21 '18 at 21:25
From your quote of the standard, I would expect"%4095p"to print out the value of the pointer padded out to 4095 bytes. Your statement you are not guaranteed that anything else will get converted for that format specifier seems to imply the pointer value might not get printed.
– jxh
Nov 21 '18 at 21:31
@jxh Reworded my answer, particularly the paragraph after the standard quote
– Govind Parmar
Nov 21 '18 at 21:36
1
@M.M What is a conforming implementation to do with a program that attempts to emit more than the environmental limits allow?
– jxh
Nov 21 '18 at 23:54
|
show 5 more comments
If you are asking specifically about the maximum width specifier, according to the C Standard, §7.21.6.1.15 (which describes fprintf; printf is described later as a specific case of fprintf):
The number of characters that can be produced by any single conversion shall be at least
4095.
This means that if, as you report, the maximum width that your C implementation's printf can handle for a format specifier before it stops working as expected is 0x7fffffe2, this is acceptable, since that satisfies the requirement of at least 4095 characters.
As for the remainder of the string not being printed out, without an MCVE, I would hazard a guess at it being a side effect of having such nonsensical width values earlier in the string. Also, %D is not a valid format specifier.
answered Nov 21 '18 at 20:44
Govind ParmarGovind Parmar
7,15553055
@M.M How exactly does the paragraph after the quote contradict anything discussed about environmental limits in the standard?
– Govind Parmar
Nov 21 '18 at 21:16
1
@M.M Really? To me it's just a restatement of the accepted answer here: stackoverflow.com/questions/27800706/… (i.e. that implementations must support at least that much, but can support more, and in OP's case, it's 0x7fffffe2)
– Govind Parmar
Nov 21 '18 at 21:25
From your quote of the standard, I would expect"%4095p"to print out the value of the pointer padded out to 4095 bytes. Your statement you are not guaranteed that anything else will get converted for that format specifier seems to imply the pointer value might not get printed.
– jxh
Nov 21 '18 at 21:31
@jxh Reworded my answer, particularly the paragraph after the standard quote
– Govind Parmar
Nov 21 '18 at 21:36
1
@M.M What is a conforming implementation to do with a program that attempts to emit more than the environmental limits allow?
– jxh
Nov 21 '18 at 23:54
|
show 5 more comments
If you are asking specifically about the maximum width specifier, according to the C Standard, §7.21.6.1.15 (which describes fprintf; printf is described later as a specific case of fprintf):
The number of characters that can be produced by any single conversion shall be at least
4095.
This means that if, as you report, the maximum width that your C implementation's printf can handle for a format specifier before it stops working as expected is 0x7fffffe2, this is acceptable, since that satisfies the requirement of at least 4095 characters.
As for the remainder of the string not being printed out, without an MCVE, I would hazard a guess at it being a side effect of having such nonsensical width values earlier in the string. Also, %D is not a valid format specifier.
answered Nov 21 '18 at 20:44
Govind ParmarGovind Parmar
7,15553055
If you are asking specifically about the maximum width specifier, according to the C Standard, §7.21.6.1.15 (which describes fprintf; printf is described later as a specific case of fprintf):
The number of characters that can be produced by any single conversion shall be at least
4095.
This means that if, as you report, the maximum width that your C implementation's printf can handle for a format specifier before it stops working as expected is 0x7fffffe2, this is acceptable, since that satisfies the requirement of at least 4095 characters.
As for the remainder of the string not being printed out, without an MCVE, I would hazard a guess at it being a side effect of having such nonsensical width values earlier in the string. Also, %D is not a valid format specifier.
answered Nov 21 '18 at 20:44
Govind ParmarGovind Parmar
7,15553055
edited Nov 21 '18 at 21:36
answered Nov 21 '18 at 20:44
Govind ParmarGovind Parmar
7,15553055
answered Nov 21 '18 at 20:44
Govind ParmarGovind Parmar
7,15553055
answered Nov 21 '18 at 20:44
Govind ParmarGovind Parmar
7,15553055
7,15553055
@M.M How exactly does the paragraph after the quote contradict anything discussed about environmental limits in the standard?
– Govind Parmar
Nov 21 '18 at 21:16
1
@M.M Really? To me it's just a restatement of the accepted answer here: stackoverflow.com/questions/27800706/… (i.e. that implementations must support at least that much, but can support more, and in OP's case, it's 0x7fffffe2)
– Govind Parmar
Nov 21 '18 at 21:25
From your quote of the standard, I would expect"%4095p"to print out the value of the pointer padded out to 4095 bytes. Your statement you are not guaranteed that anything else will get converted for that format specifier seems to imply the pointer value might not get printed.
– jxh
Nov 21 '18 at 21:31
@jxh Reworded my answer, particularly the paragraph after the standard quote
– Govind Parmar
Nov 21 '18 at 21:36
1
@M.M What is a conforming implementation to do with a program that attempts to emit more than the environmental limits allow?
– jxh
Nov 21 '18 at 23:54
|
show 5 more comments
@M.M How exactly does the paragraph after the quote contradict anything discussed about environmental limits in the standard?
– Govind Parmar
Nov 21 '18 at 21:16
1
@M.M Really? To me it's just a restatement of the accepted answer here: stackoverflow.com/questions/27800706/… (i.e. that implementations must support at least that much, but can support more, and in OP's case, it's 0x7fffffe2)
– Govind Parmar
Nov 21 '18 at 21:25
From your quote of the standard, I would expect"%4095p"to print out the value of the pointer padded out to 4095 bytes. Your statement you are not guaranteed that anything else will get converted for that format specifier seems to imply the pointer value might not get printed.
– jxh
Nov 21 '18 at 21:31
@jxh Reworded my answer, particularly the paragraph after the standard quote
– Govind Parmar
Nov 21 '18 at 21:36
1
@M.M What is a conforming implementation to do with a program that attempts to emit more than the environmental limits allow?
– jxh
Nov 21 '18 at 23:54
@M.M How exactly does the paragraph after the quote contradict anything discussed about environmental limits in the standard?
– Govind Parmar
Nov 21 '18 at 21:16
@M.M How exactly does the paragraph after the quote contradict anything discussed about environmental limits in the standard?
– Govind Parmar
Nov 21 '18 at 21:16
1
1
@M.M Really? To me it's just a restatement of the accepted answer here: stackoverflow.com/questions/27800706/… (i.e. that implementations must support at least that much, but can support more, and in OP's case, it's 0x7fffffe2)
– Govind Parmar
Nov 21 '18 at 21:25
@M.M Really? To me it's just a restatement of the accepted answer here: stackoverflow.com/questions/27800706/… (i.e. that implementations must support at least that much, but can support more, and in OP's case, it's 0x7fffffe2)
– Govind Parmar
Nov 21 '18 at 21:25
From your quote of the standard, I would expect
"%4095p" to print out the value of the pointer padded out to 4095 bytes. Your statement you are not guaranteed that anything else will get converted for that format specifier seems to imply the pointer value might not get printed.– jxh
Nov 21 '18 at 21:31
From your quote of the standard, I would expect
"%4095p" to print out the value of the pointer padded out to 4095 bytes. Your statement you are not guaranteed that anything else will get converted for that format specifier seems to imply the pointer value might not get printed.– jxh
Nov 21 '18 at 21:31
@jxh Reworded my answer, particularly the paragraph after the standard quote
– Govind Parmar
Nov 21 '18 at 21:36
@jxh Reworded my answer, particularly the paragraph after the standard quote
– Govind Parmar
Nov 21 '18 at 21:36
1
1
@M.M What is a conforming implementation to do with a program that attempts to emit more than the environmental limits allow?
– jxh
Nov 21 '18 at 23:54
@M.M What is a conforming implementation to do with a program that attempts to emit more than the environmental limits allow?
– jxh
Nov 21 '18 at 23:54
|
show 5 more comments
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%2f53419825%2fmaximum-characters-printable-by-printf-in-c%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
3
0x7ffffffeis most likely notINT_MAX.– Osiris
Nov 21 '18 at 20:17
6
Please include a MCVE that shows the problem . The exact code you used is important
– M.M
Nov 21 '18 at 20:19
INT_MAX is probably
0x7fffffffon compiler with 32 bt integers– Jean-François Fabre
Nov 21 '18 at 20:19
1
In addition to the code for the MVCE @M.M asks for you should indicate what platform you're running the test on and the compiler toolchain you're using.
– Michael Burr
Nov 21 '18 at 20:29
1
Are you asking specifically about the width value provided to a print format conversion specifier?
– jxh
Nov 21 '18 at 20:36