This thread on Hacker News terrifies me

[Patrick Schluter]

On Sunday, 2 September 2018 at 04:21:44 UTC, Jonathan M Davis 
wrote:
> On Saturday, September 1, 2018 9:18:17 PM MDT Nick Sabalausky 
> (Abscissa) via Digitalmars-d wrote:
>
> So honestly, I don't find it at all surprising when an 
> application can't handle not being able to write to disk. 
> Ideally, it _would_ handle it (even if it's simply by shutting 
> down, because it can't handle not having enough disk space), 
> but for most applications, it really is thought of like running 
> out of memory. So, isn't tested for, and no attempt is made to 
> make it sane.

One reason why programs using stdio do fail with disk space 
errors is that they don't know that fclose() can be the function 
reporting it, not the fwrite()/fputs()/fprintf(). I can not count 
the number of times I saw things like that:

     FILE *fd = fopen(...,"w");

     if(fwrite(buffer, length, 1)<1) {
       fine error handling
     fclose(fd);

on disk fullness the fwrite might have accepted the data, but 
only the fclose() really flushed the data to disk, only detecting 
the lack of space at that moment.


> Honestly, for some of this stuff, I think that the only way 
> that it's ever going to work sanely is if extreme failure 
> conditions result in Errors or Exceptions being thrown, and the 
> program being killed. Most code simply isn't ever going to be 
> written to handle such situations, and a for a _lot_ of 
> programs, they really can't continue without those resources - 
> which is presumably, why the way D's GC works is to throw an 
> OutOfMemoryError when it can't allocate anything. Anything 
> C-based (and plenty of C++-based programs too) is going to have 
> serious problems though thanks to the fact that C/C++ programs 
> often use APIs where you have to check a return code, and if 
> it's a function that never fails under normal conditions, most 
> programs aren't going to check it. Even diligent programmers 
> are bound to miss some of them.

Indeed, since some of those error checks also differ from OS to 
OS, some cases might detect things in one setting but not in 
others. See my example above, on DOS or if setvbuf() was set to 
NULL it would not possibly happen as the fwrite() would always 
flush() the data to disk and the error condition would be catched 
nearly 99.9999% of times.