Is a segfault (array index out of bounds) always the programmer's mistake or could it be misuse from the user?

  • 7
    The difference between a user and a programmer is level of abstraction they are using. – Martin Spamer Jun 28 '17 at 10:00
  • 1
    To add to @MartinSpamer 's comment, some tools allow a user to trigger this by design. gdb would be an example. – paj28 Jun 28 '17 at 16:48

10 Answers 10


Unless part of the specification is "In such-and-such a circumstance, invoke undefined behaviour" (C/C++) or "trigger an IndexOutOfBoundsException", it is always the programmer's fault.

The task of a program is to react adequately to all inputs, and that includes faulty, incomplete or even actively subversive input. In general, if the user provides unusable input, a program should give a determinate response, such as an error message or a repeat prompt, and not an implementation-defined reaction by the runtime system; such behaviour is usually not useful for the user and may cause security vulnerabilities.


No, sometimes the hardware is hit by a cosmic ray.

It is common for hardware which does not have error correction to flip a single bit when semiconductor memory is hit by high energy radiation. If this is a bit in a loop counter or an address register it will cause a the wrong address to be accessed. Software written for aerospace applications and early GPGPU software typically used redundant system and voting to get away from this where hardening the hardware was too expensive.

This NASA paper has more information on software techniques to mitigate this phenomenon, and you can always look in wikipedia for radiation hardening electronics. This paper discusses the effect of error correction in simulation on a GPU - I can't remember off-hand whether the main cause of errors in early GPUs was radiation or other soft errors.

  • 2
    At fist I was like "Damn that troll" but then... +1 is not enough – kuskmen Jun 29 '17 at 18:41
  • And of course, there are other sorts of hardware problems that can come up, too. A power surge can do wacky things to memory and hard drives, for example. It could either change the code or the data the code is working on. – user1118321 Dec 10 '17 at 17:43

As others have correctly stated, it is the programmer's fault, but since you asked for Java and C, I would like to explain the differences:

In C

Your program must prevent such a situation from happening in all circumstances, wherever it uses arrays. Make sure index variables do not run out of the array bounds. Otherwise this will result in undefined, unpredictable behaviour, and maybe security issues.

This kind of unpredictable behaviour should make it obvious why it is clearly the programmer's responsibility not to let this happen.

In Java

You can prevent this happening, but if you do not, the program will still behave in a defined manner: it will throw a specific exception. Your program then has a chance to catch this exception (and in most real world cases it should), at any level of the call stack.

If it does not, your Java runtime environment will exit the program more or less gracefully, with a technical error message which is most probably not very helpful from a user's point of view. There might be rare cases where this is acceptable behaviour. However, for most programs, as a user, if the "array out of bounds" was caused by some unexpected input parameter, I would expect the program to tell me what input parameter was probably wrong. And that does not happen automatically. One has to implement this.

So for the program not to react in a very user-unfriendly manner, it is also the programmer's responsibility to produce a more useful error message.


Yes, it is always the fault of a programmer. Either he messed up his own length calculations or he didn't properly sanitize the user input.

  • 4
    I'd change it to "a" programmers fault. You could have bad luck and encounter a bug in the platform. – whatsisname Jun 28 '17 at 7:04
  • 1
    Also, the guilty programmer could be the one that did not read the specification of the function where the segfault was triggered. Not every function has to check inputs - some state very clear requirements for inputs, and callers should heed them. – tucuxi Jun 28 '17 at 10:03
  • @tucuxi: True, that is why I said "user input", as in that what the end-user of the application does. – Bart van Ingen Schenau Jun 28 '17 at 11:49
  • 3
    women program, too – Erik Eidt Jun 28 '17 at 15:22
  • 1
    @ErikEidt - A woman wouldn't forget to sanitize :) – paj28 Jun 28 '17 at 16:56

Almost always.

Cases where it's not programmer's mistake:

  1. when it's deliberate (eg. example how to get segfault)
  2. when it's hardware malfunction
  3. when someone is/was tampering with the program or its enviroment (changing power supply, irradiating computer, changing data in memory, changing executables (but is it the original program? who is the programmer))

  4. it can be user misuse if contract specifically say that programmer cannot bill hours for dealing with unexpected input and that what happen IS undefined behavior.

  • 1
    Mitigation against deliberate attacks, in the software realm, and possibly even hardware, are the developer's responsibility. – Frank Hileman Jun 28 '17 at 23:02

could it be misuse from the user?


There are countless ways in which a user can misuse an application. Some of which no reasonable application can defend against, for example supplying the wrong libraries, pr loading an incompatible plugin.


Is a segfault ... always the programmer's mistake ... ?


Is a segfault ... sometimes the programmer's mistake ... ?

Everybody can make mistakes.

Is a segfault ... sometimes the user's mistake ... ?

Not directly.

The user will do something they believe to be valid but the application misinterprets this, generating data that causes the application code to break.

My mantra:

Bad Code breaks.  Period.  
Good Code gets broken by Bad Data. 

If the code is fundamentally wrong, it will always break. In that case, knowing where the error happened, as provided by most Stack Traces, is all you need to find and fix the problem.

If the code is basically correct but the Developer, say, missed an edge case then the code will still break, but just knowing where is not enough to fix it. You also need to know the input data that caused the breakage, which StackTraces rarely, if ever provide.


Generally speaking, if a user can crash a program by simply entering bad data at a prompt (or in a dialog box), then the programmer is definitely at fault. People make mistakes (sometimes deliberately), and a programmer who does not take that into account when implementing his or her code is being negligent. That's especially true in C, since it won't throw any kind of IndexOutOfBounds exception on indexing past the end of an array or something.

Some mistakes are failures of imagination (no way anyone would type in more than 128 characters for a single input), some are simply not considering edge cases (numeric overflow, dividing by zero, etc.). Some are the results of interactions between different pieces of code that work well in isolation, but somehow step on each other's data. We often suffer from tunnel vision when developing our code (especially when rushed), so we don't adequately exercise it with bad inputs.

Unfortunately, input sanity checking and sanitizing in C is a pain in the ass. Bulletproofing scanf is often an exercise in futility, so what many of us do is read everything in as text with fgets and then parse and convert as necessary, which causes code to balloon in size (this answer shows just how ridiculous it can get).

Now, if a user is doing something that isn't just entering input at a prompt (say, running it under gdb and messing with stuff under the hood), then that's not something a programmer can necessarily guard against.


This obviously depends on the application.

If you want to quickly hack together an application that just you use only once, it would not be sane to add thorough pointer checking. In this case, a segfault may just mean you inputted invalid data to the application. Of course, you might want to use a higher-level language such as Python, but then again if performance is important, Python may be too slow.

However, on a production-grade software, I would say that segfaults are not acceptable, and thus, it is the programmer's fault. Imagine e.g. a segfault caused by invalid network packet. That could cause your application to have a remote crash vulnerability.


For C, I would say "no". It could be user/client error. For example, not all functions which accept a pointer should necessarily waste code maintainability and computational efficiency by checking if the pointer is null if the function is documented in a way such that it's obvious that you shouldn't be passing null or dangling pointers to it. Doing that could even begin to obscure bugs elsewhere.

If you considered it the fault of the people implementing the functions, then the bulk of the C standard library is broken and buggy and in need of an epic rewrite, since you can segfault many functions in the C standard library by just passing them invalid inputs (ex: qsort past the end of a buffer). Or you can just say that anyone who passes invalid pointers to functions like qsort is using it incorrectly, and that's a much more practical view.

You can't even effectively check for the latter case (dangling pointer) anyway in a function. C functions can be infinitely misused by those who use/call them if they pass in inputs not valid for the function, so there are many cases where misuse of a C interface could be the result of "user error" in ways that lead to segfaults and other crashes.

If you want to write functions that detect programmer errors and mistakes of those using the interface, C is generally the wrong language for the job. Actually a big part of appeal to me about C is that it tends to segfault and crash spectacularly upon misuse. I prefer that to hard-to-detect bugs which can easily fly under the radar of testing.

Now I am assuming by "user", you mean someone calling a function. Not the "end-user" of an application, but the "user" of a function or library. If you're talking about end-users, then the program should never crash as the result of misuse unless they're, say, plugin developers writing C plugins for your API. Production software shouldn't be presenting, say, input fields to the user in a GUI where they can type in values too big and segfault the software. The software shouldn't allow such misuse.

Not the answer you're looking for? Browse other questions tagged or ask your own question.