Is a segfault (array index out of bounds) always the programmer's mistake or could it be misuse from the user?
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.
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:
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.
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.
Cases where it's not programmer's mistake:
- when it's deliberate (eg. example how to get segfault)
- when it's hardware malfunction
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))
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.
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 ... ?
The user will do something they believe to be valid but the application misinterprets this, generating data that causes the application code to break.
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.