Bad advice

Pages: 123
Putting any kind of reputation system in place would be putting a label on users which would ultimately discourage the beginners from posting

It seems to work on Stackoverflow pretty well. I'd even say the newcomers have more incentive to post answers there because they need those first points to do stuff like commenting, downvoting, etc, while for someone with 100k points, another 5 don't matter.
We are a different kind of site than SO though. That's more of a QA board, while this is more of a discussion board. In SO, someone asks a question, couple people answer, and that's the end of it. Here, we typically get more members in a single thread discussing the topic.

That's just my opinion, though.
Also, here we can go on a tangent that is related to the topic. On SO I asked a question, got an answer that made me think of another topic on the same point. When I asked the second question they closed it after telling me to ask new questions in a new post :/. Those were the only two questions I ever asked on SO and started posting here, though lately it seems I've been mostly posting to lounge threads and answering beginner questions than asking my own.
1_ That's a code change. However you could use the link magic.
2_ Nope, there is no such guarantee. Also, ┬┐what would happen if I've got another global, whose destructor I'm interest in?
3_ But you don't clean the buffer, so there could be a line break stored.
Also, there is getch() in ncurses.

on topic:
I think it makes sense to change a response reputation.
Translating that to the user is incorrect.

I think 1000 is a safe number at this point, but even then there are exceptions (*points to self*).

:) weren't exceptions const integers*? Is this a a static cast there?
I like however the use of

*[Edit:]They are not, my bad!

here is a copy+paste from stack overflow:

This is defined in 15.1 Throwing an exception of the standard.

The throw creates a temporary object.
How the memory for this temporary object is allocated is unspecified.

After creation of the temporary object control is passed to the closest handler in the call stack. unwinding the stack between throw and catch point. As the stack is unwind any stack variables are destroyed in reverse order of creation.

Unless the exception is re-thrown the temporary is destroyed at the end of the handler where it was caught.

Note: If you catch by reference the reference will refer to the temporary, If you catch by value the temporary object is copied into the value (and thus requires a copy constructor).

Advice from S.Meyers (Catch by const reference).
Last edited on
I don't like reputation points. I am occasionally wrong, also.

There is no fool-proof method to do the stupid PAUSE trick outside of executing the program from a parent program that does the pausing after the child process terminates.

After that big, long thread, it seems that people have still missed the problem with system("PAUSE"): it subverts system security. Almost as bad as that is that users (on Windows at least, where this is an issue) get nasty messages from their anti-virus programs warning them that your program is doing something uncouth. Finally, I think I was pretty careful to explain how the stupid pause trick takes control away from your users when they use your programs.

Granted, the thread is a long read, but if someone really wants to intelligently discuss the issue (at least on this forum) without sounding like he hasn't done his homework, he ought to have read through it. It is, after all, nicely stickied at the top.
Duoas wrote:
... outside of executing the program from a parent program that does the pausing after the child process terminates.

In case anyone is wondering this is EXACTLY what Code Blocks does when you execute a program from within the IDE. You can see your executable spawned as a child process with Process Explorer.

As far as there not being a fool-proof way of doing this, I'm wondering if we should take the stance of encouraging even brand new users to use a proper execution loop:
    /*Execute Main Body Of Your Program Here*/
    /*Get User Input Here*/
while(UserInput != Some_Condition);

This is how most application end up being anyway, at least the ones I write.
Last edited on
After that big, long thread, it seems that people have still missed the problem with system("PAUSE"): it subverts system security.

... and then you mention anti-viruses catching that. 1995 1998 called, they want their security expert back.

Edit: toned down the harshness.
Last edited on
and then you mention anti-viruses catching that. 1995 called, they want their security expert back.

Not all of them catch it. For example, AVG (Which is what I use because it's free and I don't go to sketchy sites) does not catch it. I've ran multiple system calls just to see if it would.
The system call false positive issue has been resolved for a few years now on pretty much all major antivirus suites.
@ ResidentBiscuit: Have you tried replacing pause.exe with a trojan?
@ Catfish2: What the heck is pause.exe? I promise you that no such application with that name exists on any clean Windows installation. The command pause is a command to the shell, the shell itself is what gets compromised, either by changing the start up process in the registry or replacing cmd.exe with a virus, and the system() function automatically uses the security credentials of the application that called it. Since programmers are System Administrators 99% of the time this can get very bad very quickly.
I'm pretty sure it's pause.exe. What do you think a shell command is if not a program?

But if someone is able to replace pause.exe with malware, couldn't they just as easily replace a number of other processes instead? If they have access to your system32, and the permissions, they could wreak total havok on your system anyways.
Last edited on
I'm pretty sure it's pause.exe. What do you think a shell command is if not a program?

From what I checked, Computergeek01 is right. I got confused because I could run pause.exe in the Command Prompt.
I also noticed that the pause command has priority over an executable pause.exe in the current directory.
@ iseeplusplus: A shell command is exactly that, a command to the shell. Open a command line and type in "Path", this will give you all of the default search paths that your command line shell checks if it cannot find the application you are calling in the directory you are currently in. I guarantee there is no "pause.exe" in any of those locations. You can further verify this by calling pause inside of the command line and looking at your task manager, there will be no pause.exe running in memory while that shell is on hold where as if you run something like telnet, which is an application and NOT a shell command, you would see it as a child process of that shell.

You can also place an executable called "pause.exe" in any location that was previously displayed from your call to path and see that the command to the shell gets executed while your executable is ignored. Removing the .exe extension prevents Windows from identifying what type of file it is and prevents it from executing at all without you telling Windows what application to open it with.

If you don't want to do any of this then just go to Start -> Run -> "Pause.exe" and watch as nothing happens.

EDIT: If it helps to clarify this further other examples of shell commands are "copy", "Del" and "echo" which do not appear anywhere in the systems search path. Where as examples of applications are "telnet", "ipconfig" and "arp" all of these application examples are visible as executable files in C:\Windows\system32.
Last edited on
Interesting. For some reason I had always thought it was pause.exe. Can you go into more detail about how the pause command could be corrupted?
Why not, nothing like a thread titled "Bad Advice" to go over some simple attack vectors.

It's not the pause command that is vulnerable, it's the command shell "cmd.exe". If this executable is overwritten Windows will not care, it will simply execute whatever version of cmd.exe it finds and that's that.

Another method of compromising this would be an image hijack. This is done by editing the registry key "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options". You add a key called "cmd.exe" to the list, inside that key you create a string value titled "Debugger" and for the value you enter the path and the name of the executable you want to run in place of "cmd.exe". This will probably prevent your application from compiling so do that before testing this method out. Then run your program and see that any call to cmd.exe runs the application you inserted as a string value instead. When you are done to restore cmd.exe simply delete the key you created. NOTE: This will work to hijack the vast majority of programs in Windows and is a VERY popular attack vector for virus authors.

These are just two of the many many techniques that you will run into as long as you're that guy that everybody knows who can get that virus off of their computer.
If you don't want to do any of this then just go to Start -> Run -> "Pause.exe" and watch as nothing happens.

Isn't that exactly what a Pause command should do?
Best way to keep the console output up -- run the program through the console :)
I'm new here, both to C++ and the forum. First thing I did was go through the forum and came across that "Keep console open" thread. Personally, I find that there is something to learn on both sides. For one, I learned how to keep the console open, and for many, how the hell not to do that. I think it's only fair to teach both sides, because if I didn't know why, I might end up spending a fairly long time doing exactly that, because a beginners point of view: if it works, it's valid.

One thing I do think that could be useful is a "recommended" button, which gets a direct link at the start of the topic (multiple links possible?). It would not damage the content in the forum, but it certainly would help those that just want to skim through.

Imagine a situation where you have a question, google directs you here, and you end up reading an entire topic of useless comments, just to find one guy at the end that solves it.
At some point, you just don't want to do that.

On the topic of pause.exe, I think you should see it more as a function than a program. It's a call inside cmd, and cmd takes care of it all. For some more complex matters, like for example powershell, telnet, etc, it executes a console application within itself. Basically what I think that happens is "cmd.exe -pause.exe"
Last edited on
Pages: 123