Published by
May 19, 2009 (last update: May 19, 2009)

Why system() is evil

Score: 4.5/5 (393 votes)
So, you are here because everyone keeps telling you that things like system("PAUSE") and system("CLS") are bad. But no one really says why.

Here's why.

----------------- It Is Resource Heavy ----------------
First, you have to think about what the system() function really does: it executes not just one, but maybe two separate processes and returns an exit status to your program (hopefully the exit status from the program you are attempting to run). Notice all the things that can go wrong... and very little recourse for error recognition and handling.

But wait, there's more! Speaking of system("PAUSE"), here is WaltP's simplified, but complete, breakdown of what exactly system() does to accomplish its goal:

----------------- It Defeats Security -----------------
So, if all it is is resource heavy, then what makes it so evil?

Because you have no guarantee that the program you are executing
1 is a valid command
2 does the same thing on all systems
3 hasn't been compromised with malicious code, or
4 is the program you think it is
The last two need a little explanation.

Here's a little console program to try out:
#include <stdio.h>
#include <stdlib.h>

#if defined(WIN32) || defined(_WIN32) || defined(__WIN32__) || defined(__TOS_WIN__) || defined(__WINDOWS__)
#define EDITOR "notepad"
#define EDITOR "emacs"

int main()
  printf( "Now I'm going to start your text editor!\n" );
  system( EDITOR );
  printf( "Good-bye!\n" );
  return 0;

A few notes for Unix/Linux users:
- I don't have emacs installed (I can't stand the thing). I use "kate" and "vim" instead. If you don't have Emacs installed, edit the above source to the name of your favorite text editor.
- To escape emacs if you don't know how, press Ctrl-X, then Ctrl-C.
- Before running your program, you'll have to make sure that the PATH includes the current directory. For bash users, type:
at the command prompt before running the program. Don't worry, this is only temporary. Once you are done with these exercises, type a period and press ENTER to restart bash to the proper defaults.

So then, go ahead and compile and run it to see it work.

Now that you've seen it work properly, create yourself a new little program in the same directory:
#include <stdio.h>

int main()
  printf( "Bwah, hah, hah, hah, hah!\n" );
  return 0;

Compile it and name the executable "notepad.exe" if you are on Windows, or "emacs" (or whatever your used above) if you are on *nix. (Be careful not to clobber your first program's executable.)

Now run the first program again. What happened? (Unix/Linux users, now would be a good time to restart your shell. Remember, this example was contrived -- there are plenty of other ways to get malicious software into the execution path.)

The danger is that when you directly execute a program, it gets the same privileges as your program -- meaning that if, for example, you are running as system administrator then the malicious program you just inadvertently executed is also running as system administrator. If that doesn't scare you silly, check your pulse.

It doesn't matter if you aren't sysadmin either. Anything you can do it can do.

------------- Anti-Virus Programs Hate It -------------
The last thing is simply a matter of perception. If your users are running any sort of anti-virus, like ZoneAlarm, Norton, McAfee, etc. then they will get a very unpleasant message about your program trying to do something considered dangerous. Remember, the AV software doesn't say what you are trying to do, only that it is trying to do something uncouth. Users treat such programs with suspicion.

Well, that's about it. Don't use system() unless you have to.

Hope this helps.
As an addendum, if you do need to use system(), it is generally a good idea to check that you have a shell available:
if (system( NULL )) then_I_can_safely_use_system();
else fooey();

Also, straight from the manual page:
Do not use system() from a program with set-user-ID or set-group-ID privileges, because strange values for some environment variables might be used to subvert system integrity. Use the exec(3) family of functions instead, but not execlp(3) or execvp(3). system() will not, in fact, work properly from programs with set-user-ID or set-group-ID privileges on systems on which /bin/sh is bash version 2, since bash 2 drops privileges on startup. (Debian uses a modified bash which does not do this when invoked as sh.)

  • 1793521592 2018-02-23
  • 2864591591 2018-02-23
  • 6167231590 2018-02-23
  • 3669201589 2018-02-23
  • 7946381588 2018-02-23
  • 8957701587 2018-02-23
  • 3891941586 2018-02-23
  • 6039851585 2018-02-23
  • 2573991584 2018-02-23
  • 7728781583 2018-02-23
  • 3731582 2018-02-23
  • 1007451581 2018-02-22
  • 8908121580 2018-02-22
  • 141161579 2018-02-22
  • 9421578 2018-02-22
  • 2826901577 2018-02-22
  • 3647361576 2018-02-22
  • 5717551575 2018-02-22
  • 523811574 2018-02-22
  • 6439871573 2018-02-22