I'm surprised by nonchalance about bad inputs evoking bad program behavior. That attitude may have been excusable 50 years ago. By now, though, we have seen so much malicious exploitation of open avenues of "undefined behavior" that we can no longer ignore bugs that "can't happen when using the tool correctly". Mature software should not brook incorrect usage.
Accepting bad inputs can also lead to security issues. The data breaches from SQL-based attacks are a modern case in point.
IMO, as a programmer you owe it to your users to do your best to detect bad input and to handle it in a graceful fashion. Nothing is more frustrating to a user than to have a program blow up in their face with a seg fault, or even worse, simply exit silently.
As the DEC compiler team's expert on object files, I was called on to add object file support to a compiler back end originally targeted to VMS only. I inherited support of the object file generator for Unix COFF and later wrote the support for Microsoft PECOFF and ELF. When our group was bought by Intel I did the object file support for Apple OS X MACH-O in the Intel compiler back end.
I found that the folks who write linkers are particularly lazy about error checking and error handling. They assume that the compiler always generates clean object files. That's OK I suppose if the compiler and linker people are in the same organization. If the linker falls over you can just go down the hall and have the linker developer debug the issue and tell you where you went wrong. But that doesn't work when they work for different companies and the compiler person doesn't have access to the linker sources. I ran into a lot of cases where my buggy object file caused the linker to seg fault or, even worse, simply exit without an error message.
I ended up writing a very thorough formatted dumper for each object file format that did very thorough checking for proper syntax and as many semantic errors (e.g., symbol table index number out of range) as I could.
-Paul W.