• Advertisement

JulieMaru-chan

Member
  • Content count

    137
  • Joined

  • Last visited

Community Reputation

356 Neutral

2 Followers

About JulieMaru-chan

  • Rank
    Member

Personal Information

Social

  • Github
    onpon4
  1. "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. 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.
  2. 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). 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.
  3. "Deprecated" has a specific meaning: features that are slated for removal in a future version. It does not mean "not recommended". Legacy C code is not deprecated in C++, and that goes for strcpy and sprintf as well. You'll be able to use them for the foreseeable future. (The strings themselves obviously can't be deprecated, since they're literally just char pointers.) C strings are not inherently buggy, by the way, let alone "unsafe". They just need to be used correctly. 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.
  4. Since when are C strings deprecated?
  5. C strings are perfectly fine if you use them correctly. That entails not reformatting the same string multiple times, and using the strcpy function to copy strings, not sprintf. I disagree with the implicit suggestion that you should use C++ strings for new code while keeping C strings for old code. The most important aspect when it comes to readability is consistency, so if you're using C strings everywhere, starting to use C++ strings some places while keeping it as C strings in other places will make your code harder to read, and that's a problem. That's why my suggestions haven't been "ditch C strings" like everyone else, but rather "use C strings correctly". The only other suggestion I would make is that if you prefer the C style (as I do; I think C++ is an ugly language), you should use C, not C++. That also means you use e.g. malloc and free instead of new and delete, a good naming convention instead of namespaces, and regular structs instead of classes. But you don't have to migrate already existing projects (C style programming support for C++ isn't going away), and if you choose to do so, you don't have to do it overnight.
  6. You're using sprintf wrongly, and that causes reformatting. Change that to this: https://pastebin.com/sj2ugGEt Or, even better, since you just need to copy the string, use strcpy instead of sprintf: https://pastebin.com/BiYk356C (Using Pastebin because the forum keeps erasing half my post when I try to use two code tags.) Repeat for all affected functions.
  7. So, why can't these functions you're sending the string to just not format the string that's sent to them, like in the example I posted? I'm still not understanding why you're formatting arbitrary strings. An example of one of these functions would be nice.
  8. Is there any particular reason you're formatting a string several times? It seems to me this is something you should be avoiding. If you're appending something, you should format only the appended portion, e.g.: sprintf(newstr, "%s\nNext stat: %d", oldstr, newstat) I can't think of any case where this would be difficult, and it seems to me that reformatting the same string over and over again is a recipe for hard-to-solve bugs. (No comment on the C++ stuff some others have posted; I'm not very familiar with the C++ ways.)
  9. Web game getting published without permission

    I thought I said that explicitly, but other than that, yes. I am in favor of capitalism and free markets. No (at least, not in the way you're thinking). There's nothing wrong with commercial exploitation, and that includes charging money for copies if you figure that is an effective business model. That's an invalid question because people do make things with no expectation of reward all the time. It's so common that listing examples would be silly. It's also an invalid question because I'm not opposed to seeking a reward for work. In fact I encourage it. My key points are that copyright is obsolete, and censoring your own work because it's not directly making you money is counterproductive. It's hard to make a specific recommendation without knowing what kind of game it is, but given that these unauthorized copies are by and large your primary source of users, the smart thing to do is to use that situation to your advantage to make money indirectly from it.
  10. Web game getting published without permission

    And I'm saying you shouldn't care about that, and in fact you should explicitly allow it in the game's license. It helps you, and you can take advantage of it. This is not even a new concept. Doom only became as successful as it did because there was a free version that anyone was allowed to distribute, and even sell. id Software didn't make much from Doom. But they took advantage of the free publicity they got, and the rest is history. Stopping other people from making money off your work by doing something you can benefit from is like refusing to show up to your job at McDonald's because the restaurant is making money from your work that they aren't giving to you. You have it backwards. Copyright is a monopoly that has to be legally enforced. What gives someone the right to "create a revenue stream", as you call it, is that they own the server that is doing the lifting and of course they have a right to make money while providing a service to their visitors. The only reason it's illegal is that there is a law (copyright) that says you're not allowed to share, and I think that law is unjust and outdated. I'm well aware. That's why my suggestion included lifting those copyright restrictions.
  11. Web game getting published without permission

    If you're upset that people are actually playing your game because someone else decided to promote them for you, using their infrastructure, then by all means censor your own game with copyright law. But I think that is absurd. I would love for my games to be redistributed en masse without me having to do any work, and I never want my work censored. Furthermore, what exactly do you expect is going to happen when you censor the copies of the game that people are actually playing? You would be a fool to think they would just flock to the official version. No, they would simply stop playing and move on to something else.
  12. Web game getting published without permission

    I'm going to go against the grain and recommend that you rejoice that people think highly enough of the game you made to redistribute it for you. In fact, you should explicitly grant people permission to do so and actively encourage it. Then take advantage of it; add a donation link to the game, put in ads, use it to promote some other money-making venture, or what have you.
  13. Game scripts - where can I find them for writing examples?

    Just use gettext. That's what I do. You can even auto-detect the strings that need to be translated with xgettext, and then localization is just a matter of using msginit, then filling in the values in the created .po file.
  14. Game scripts - where can I find them for writing examples?

    Flare RPG (the Empyrean Campaign) was finished recently, so that's probably a good example: http://flarerpg.org/
  15. Jumping The Same Height At All FPS

    I managed it just fine with the xacceleration and yacceleration attributes of objects in the SGE Game Engine. I followed the suggestion of a coworker at the time and used the kinematic equations. Source code is here if you want to see the specifics: https://savannah.nongnu.org/git/?group=stellarengine
  • Advertisement