That’s a failure of requirements analysis.
That’s why formal verification people like pure functional languages. The inputs are the parameters. The output is the return value. And no side effects are allowed.
Of course, an actual implementation of a functional language can’t make those claims. But it is much less likely that a program that is not trying to touch the disk at all is going to overwrite files willy nilly.
I think I’ve checked the return value of printf() at least once, but it was probably in the context of a programming class on the topic of validation. Though, if it does fail, what do you do then? Return an error message? And what if fprintf to stderr fails also?
One of my most awestruck moments as a teacher was when I was teaching a week-long summer camp on video game design, mostly using Scratch. One of my students, a middle-schooler, decided to add a high scores list to his game, which required asking the high-scoring player to type in their name. Which he then proceeded to do input validation on. With no prior programming experience at all, according to both him and his parents.
I used to check the output of the various library print functions all the time. But that was quite a while ago, when some compilers or implentations would have bugs. I think there was a serious buffer oveflow issue with an implentation of printf() at one point.
Then there’s sprintf, fprintf, and about a million overloads of these functions. So yeah, assuming they all work flawlessly all the time is not a good idea. But hopefully proper unit testing of the functions that call them will suffice.
There wasn’t an option for my ‘correct’ status. I’m a former developer who recognized the phrase. But I moved on to other endeavors years before the phrase was coined. The only development I do these days is Powershell scripting for task automation. In my days it was called Monkey testing.
After what I said about fuzz testing, I find out that I had this video in one of my tabs, that I hadn’t yet watched:
