Why does printf_s exist?
-
According to MSDN[^], "The main difference between
printf_sandprintfis thatprintf_schecks the format string for valid formatting characters, whereasprintfonly checks if the format string is a null pointer." So, basically, if I understand correctly, it's not really a security feature as its name implies, it's a debug feature. The whole "uncontrolled format string" problem it's supposed to solve could be avoided by basic knowledge of whatprintfactually does. EDIT: I don't even know why I'm not just usingcoutprintf is not sexist... OK, I'll take my coat...
[www.tamautomation.com] | Robots, CNC and PLC machines for grinding and polishing. [YouTube channel]
-
printf is not sexist... OK, I'll take my coat...
[www.tamautomation.com] | Robots, CNC and PLC machines for grinding and polishing. [YouTube channel]
-
According to MSDN[^], "The main difference between
printf_sandprintfis thatprintf_schecks the format string for valid formatting characters, whereasprintfonly checks if the format string is a null pointer." So, basically, if I understand correctly, it's not really a security feature as its name implies, it's a debug feature. The whole "uncontrolled format string" problem it's supposed to solve could be avoided by basic knowledge of whatprintfactually does. EDIT: I don't even know why I'm not just usingcoutby "security" what they mean is that additional check(s) are being done.
-
More importantly, why are you using C ? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
C is cool. :cool:
-
More importantly, why are you using C ? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
Depending on the target system, I would use C anytime. Especially for older systems or microcontrollers C is still a very good choice. For example, I have a C compiler that compiles for the old 6502 CPU. With a relatively simple hardware abstraction layer, you can easily write programs that run on 8 bit Atari computers, 8 bit Commodore computers or an Apple II. I still have several Ataris and also two C64 and can write and compile programs on the PC, test them in emulators and then transfer them to the real thing when finished.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
According to MSDN[^], "The main difference between
printf_sandprintfis thatprintf_schecks the format string for valid formatting characters, whereasprintfonly checks if the format string is a null pointer." So, basically, if I understand correctly, it's not really a security feature as its name implies, it's a debug feature. The whole "uncontrolled format string" problem it's supposed to solve could be avoided by basic knowledge of whatprintfactually does. EDIT: I don't even know why I'm not just usingcouttomatopipps wrote:
EDIT: I don't even know why I'm not just using
coutThe compiletime overhead?
Espen Harlinn Chief Architect - Powel AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
According to MSDN[^], "The main difference between
printf_sandprintfis thatprintf_schecks the format string for valid formatting characters, whereasprintfonly checks if the format string is a null pointer." So, basically, if I understand correctly, it's not really a security feature as its name implies, it's a debug feature. The whole "uncontrolled format string" problem it's supposed to solve could be avoided by basic knowledge of whatprintfactually does. EDIT: I don't even know why I'm not just usingcoutBecause Microsoft. That's why.
What do you get when you cross a joke with a rhetorical question? The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism. Do questions with multiple question marks annoy you???
-
Because Microsoft. That's why.
What do you get when you cross a joke with a rhetorical question? The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism. Do questions with multiple question marks annoy you???
Hardly.
print_sand related functions are part of the C and C++ standard libraries: http://en.cppreference.com/w/c/io/fprintf[^].Software Zen:
delete this; -
According to MSDN[^], "The main difference between
printf_sandprintfis thatprintf_schecks the format string for valid formatting characters, whereasprintfonly checks if the format string is a null pointer." So, basically, if I understand correctly, it's not really a security feature as its name implies, it's a debug feature. The whole "uncontrolled format string" problem it's supposed to solve could be avoided by basic knowledge of whatprintfactually does. EDIT: I don't even know why I'm not just usingcoutIt's a security feature because by ensuring a parameter is valid, it can prevent unchecked input, crashes and so forth. https://en.wikipedia.org/wiki/Uncontrolled_format_string[^] printf has a flexibility and control that cout doesn't provide. I've also found that ostream can be very slow. Not a big deal or console output, but can stack in other places.
-
It's a security feature because by ensuring a parameter is valid, it can prevent unchecked input, crashes and so forth. https://en.wikipedia.org/wiki/Uncontrolled_format_string[^] printf has a flexibility and control that cout doesn't provide. I've also found that ostream can be very slow. Not a big deal or console output, but can stack in other places.
printf(or its secure variants these days) has an economical expressiveness thatcoutcan't provide. It's interesting that thestring.Format(...)model in .NET is moreprintf-like than anyone would like to admit. Granted, it 'cheats' and uses the CLR type mechanism to guarantee reasonable behavior, but I still like it better than thecoutmodel.Software Zen:
delete this; -
It's a security feature because by ensuring a parameter is valid, it can prevent unchecked input, crashes and so forth. https://en.wikipedia.org/wiki/Uncontrolled_format_string[^] printf has a flexibility and control that cout doesn't provide. I've also found that ostream can be very slow. Not a big deal or console output, but can stack in other places.
> printf has a flexibility and control that cout doesn't provide. Say what? What kind of flexibility does printf offer that cout lacks? (The entire purpose for cout's existence is to be more flexible than printf)
Truth, James
-
More importantly, why are you using C ? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
According to MSDN[^], "The main difference between
printf_sandprintfis thatprintf_schecks the format string for valid formatting characters, whereasprintfonly checks if the format string is a null pointer." So, basically, if I understand correctly, it's not really a security feature as its name implies, it's a debug feature. The whole "uncontrolled format string" problem it's supposed to solve could be avoided by basic knowledge of whatprintfactually does. EDIT: I don't even know why I'm not just usingcouttomatopipps wrote:
The whole "uncontrolled format string" problem it's supposed to solve could be avoided by basic knowledge of what
printfactually does.Nope. Its needed because, despite knowing what printf actually does, people still get it wrong. In my experience, a large percentage of C program crashes were precisely because of a mismatch in printf format strings and arguments, often in non-happy-case code paths that clearly were never tested.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
According to MSDN[^], "The main difference between
printf_sandprintfis thatprintf_schecks the format string for valid formatting characters, whereasprintfonly checks if the format string is a null pointer." So, basically, if I understand correctly, it's not really a security feature as its name implies, it's a debug feature. The whole "uncontrolled format string" problem it's supposed to solve could be avoided by basic knowledge of whatprintfactually does. EDIT: I don't even know why I'm not just usingcout"I don't even know why I'm not just using cout" Because the printf family of functions are drastically easier to use than cout?
-
> printf has a flexibility and control that cout doesn't provide. Say what? What kind of flexibility does printf offer that cout lacks? (The entire purpose for cout's existence is to be more flexible than printf)
Truth, James
James Curran wrote:
What kind of flexibility does printf offer that cout lacks?
for one example, I find:
printf("%0.3f %.2f", x, p);More clear and concise than:
cout << std::fixed << std::setprecision(3) << x << " " << std::defaultfloat << std::setprecision(3) << p;Also, something like a logging function where the formatting happens after a series of checks, is easier to write using the printf family. Finally, using snprintf family can be extremely useful, especially in combination with the logging issue. PS. In several cases, I do prefer the ostream family. It all depends on what I'm trying to accomplish with the code. (There is a huge chunk of diagnostic code in the project I'm current working on which uses lots of CString::Format (snprintf_s internally), which would be a whole lot more readable using ostringstream, but I'd likely be shot if I changed it.) EDIT: Visual Studio 2010 and especially 2013 have really optimized ostream functionality. I wrote a quick test using some code from the aforementioned project. Using ostringstream was 17% faster than CString::AppendFormat with VS 2010 and 30% faster with VS 2013. I wouldn't be surprised if VS 2015 offers more improvement.
-
James Curran wrote:
What kind of flexibility does printf offer that cout lacks?
for one example, I find:
printf("%0.3f %.2f", x, p);More clear and concise than:
cout << std::fixed << std::setprecision(3) << x << " " << std::defaultfloat << std::setprecision(3) << p;Also, something like a logging function where the formatting happens after a series of checks, is easier to write using the printf family. Finally, using snprintf family can be extremely useful, especially in combination with the logging issue. PS. In several cases, I do prefer the ostream family. It all depends on what I'm trying to accomplish with the code. (There is a huge chunk of diagnostic code in the project I'm current working on which uses lots of CString::Format (snprintf_s internally), which would be a whole lot more readable using ostringstream, but I'd likely be shot if I changed it.) EDIT: Visual Studio 2010 and especially 2013 have really optimized ostream functionality. I wrote a quick test using some code from the aforementioned project. Using ostringstream was 17% faster than CString::AppendFormat with VS 2010 and 30% faster with VS 2013. I wouldn't be surprised if VS 2015 offers more improvement.
aha... But you didn't say "concise" you said "flexible". I totally agree, printf is way more concise that cout, but for flexibility :
Point p(2,3); cout << p << endl;beats
printf("(%d, %d)\\n", p.x, p.y);Truth, James
-
According to MSDN[^], "The main difference between
printf_sandprintfis thatprintf_schecks the format string for valid formatting characters, whereasprintfonly checks if the format string is a null pointer." So, basically, if I understand correctly, it's not really a security feature as its name implies, it's a debug feature. The whole "uncontrolled format string" problem it's supposed to solve could be avoided by basic knowledge of whatprintfactually does. EDIT: I don't even know why I'm not just usingcout