Printing % to a string? I need MANY % to get the percent symbol

Started by
23 comments, last by diligentcircle 6 years ago

True. Just as plain old C-style casts. And even if C-style casting will most of the time work as expected in C++, this is not something a C++ programmer should reasonably do.

In fact, this is not easy in C++ to deprecate language features that exists in C. The only keyword I know which was deprecated is 'register' (in C++ 17). But it has been reserved and this is something C++ specific.

Also, we are now in C++ 17. And as other posters pointed it, there are very old functionalities and features in C++ that, if used, will one day or another, reveal bugs, security issues... Unfortunately nothing can prevent anyone to use them, but this is at the author's own and now well known risk.

4 hours ago, JulieMaru-chan said:

If you're going to argue that any language feature that can be used incorrectly in dangerous ways is a problem, then C++ certainly isn't a language you would turn to.

I guess, and to my own opinion, that this is wrong. Why ? C++ (and C) are languages that are not safe by conception. Pointers allow to use the language in dangerous ways. Letting the programmer manages the memory allow that too. Unsafe functions allow it too. And inherently, all common security risks/bugs you are aware of (buffer overflow...) are common security issues in programs written in C (and C++) most of the time due to mistakes when programming (sprintf is a well-known open door to such attacks). And such uses are responsible of the majority of security risks in most of the programs. So yes, these are problematic and should not be used.

There are languages that, by design, prevent as most as possible to be used 'badly'. Java and C# are examples of such languages (less for java from what I know). But clearly, system languages as C and C++ are languages that allow to be used in dangerous ways. A simple example of this is that you can do 'hacking' with these languages. C++ protects things a bit more, but then confine to C++.

Just as a little example. Imagine you release a game, some kind of MMORPG with let say 100K players. Each player pays every months for playing your game. Each player pays even more to get some upgrades. And now, your programs make the use of sprintf, scanf (and many other well known dangerous functions). Everything is fine until one day a big attack happens on your servers and clients, massively and takes credit card numbers of all your clients...

And even if that never happens, doing things well (mainly if you are aware of it), is important, just like you stated for the consistency in your previous post :)

Advertisement

there are very old functionalities and features in C++ that, if used, will one day or another, reveal bugs, security issues...


Sorry, this doesn't make any sense. sprintf and strcpy are not old and unmaintained features in a program, they're standards (and very important ones) of C that C++ also inherits. I think you're talking about bugs and security problem caused by the programmer using the features wrongly. But if any feature, regardless of how you feel about it, is used correctly, there's no problem.

As far as C-style strings go, they're what you have to use in C, and plenty of C programs (some popular ones: Linux, Python) get by just fine. I don't even think sprintf is anywhere near as dangerous of a feature as simple pointers, which C++ programmers use all the time. So again, if dangerous language features are something you consider to be a serious problem, you wouldn't turn to C++, you would turn to something safer like Java or Python or even C# (as you mentioned).

And now, your programs make the use of sprintf, scanf (and many other well known dangerous functions). Everything is fine until one day a big attack happens on your servers and clients, massively and takes credit card numbers of all your clients...


Credit card information gets stolen by crackers because of bad programming, not because you use C style programming methods. Blaming sprintf for such an attack is like blaming the screwdriver for damage you did by screwing something in way too tight. So in the example you present, that big attack could have happened whether they used sprintf or not.

And again, if you're concerned about protecting programmers from their own stupidity, C++ isn't going to be a solution. To be perfectly honest, you'd have to be a very bad programmer to misuse sprintf in such a way that it's the only reason credit card information gets stolen. I think you'd be more likely to misuse pointers in such a way.

I would also like to point out that mixing two styles together can potentially leave you more vulnerable to security vulnerabilities as well, since it makes your code inconsistent and therefore harder to read. When code is harder to read, it's much easier for security problems to go unnoticed.

2 hours ago, JulieMaru-chan said:

Credit card information gets stolen by crackers because of bad programming, not because you use C style programming methods.

But who said the opposite ? Since the begining of this thread some people and I are just strongly suggesting not to use C functions anymore, and to prefer C++ functionalities. 

Use C functions if you want, they work for sure and std strings are based on C char arrays and some (safe) C functions.

 

2 hours ago, JulieMaru-chan said:

As far as C-style strings go, they're what you have to use in C

Not forcelly. There are some libraries allowing to do and manipulate strings in a more safe manner. Glib is one example. And I'm sure many other exist. And they don't exist just to be beautiful.

 

2 hours ago, JulieMaru-chan said:

if you're concerned about protecting programmers from their own stupidity, C++ isn't going to be a solution.

But no one said that neither ! I have the impression you took it all the wrong way. No one talked about stupidity or that any language is the safest in the world...

 

If you have to repeat a thing 10k times. Will it be safer to use unsafe char arrays, coupled with several unsafe C functions or will it be more safe to use more safe C++ strings with more safe C++ functionalities. That's all about.

 

Take it easy and simple JulieMaru-chan. This is all about giving good tools to use and damn knows this is not an easy thing ! Not to talk about stupidity or language supremacy.

 

For more information:

https://social.msdn.microsoft.com/Forums/vstudio/en-US/c678c966-2b25-4ee5-a8de-3835418e2c65/sprintf-depreciated-so-what-do-we-use?forum=vclanguage

https://www.gnu.org/software/libc/manual/html_node/Formatted-Output-Functions.html

http://spc.cs.ucdavis.edu/index.php/situations/format-string-vulnerabilities

But who said the opposite ? Since the begining of this thread some people and I are just strongly suggesting not to use C functions anymore, and to prefer C++ functionalities.



"And now, your programs make the use of sprintf, scanf (and many other well known dangerous functions). Everything is fine until one day a big attack happens on your servers and clients, massively and takes credit card numbers of all your clients..."

Granted, you didn't say anything specific, but you did strongly imply here that using what you call "dangerous functions" is what causes security vulnerabilities.

All I'm saying is that these functions are tools. They can be used safely and properly, and when you do so they can be very useful. They can also be misused, but that's no basis to blame the tool when a programmer does something they shouldn't.

If you have to repeat a thing 10k times. Will it be safer to use unsafe char arrays, coupled with several unsafe C functions or will it be more safe to use more safe C++ strings with more safe C++ functionalities. That's all about.


I think both would be equally safe if you know what you're doing. The worst thing you could do is to try to use a mixture of the two in a way that makes your source code harder to read.

This is the primary disagreement we have. You say to gradually migrate to the C++ way because it's "safer", and mix the two together in the meantime. I say to stick with the C style because you're already using it, and keeping consistent code is more important than doing things the "better" way.

This topic is closed to new replies.

Advertisement