[OT] OT: Null checks.

[Walter Bright]

 > The user is certainly not willing to use a DMD build for two months.

As DMD will give you a compiler error message if it can statically determine 
(using Data Flow Analysis) there's a null dereference, you've found the problem. 
You won't need to send it to your customer. I'd turn on function inlining, too, 
which extends the reach of the static DFA.

If DMD does not detect any such, then unless LDC is doing a lot of 
interprocedural DFA, then LDC is not deleting UB null dereferences. If you do 
get a null dereference when executing the program, it will exhibit as a seg fault.

I read that the latest gcc/llvm compilers will give a warning if deleting UB. If 
in your case no such warning is given, then it is not deleting UB, and this is 
not an issue for the bug your user is experiencing.

 > druntime is riddled with code that builds an error message and then does 
assert(0, msg);. x)

Here are the compiler options for responding to assert failures:

Behavior on assert/boundscheck/finalswitch failure:
   =[h|help|?]    List information on all available choices
   =D             Usual D behavior of throwing an AssertError
   =C             Call the C runtime library assert failure function
   =halt          Halt the program execution (very lightweight)
   =context       Use D assert with context information (when available)

What you can do is use the -checkaction=C option, and then write your own 
version of the C runtime library assert failure function. Writing your own will 
prevent the linker from pulling it in from the C runtime library (i.e. it 
overrides it). You can then have it do whatever you need done.

Druntime also uses a function pointer for assert failures where you can set it 
to point to your own handler.

 > Well, I have no idea where the crash happens and getting one log file every 
couple months (and writing out gigabytes of useless log files in the meantime) 
seems not workable. It would be much better to be able to react to the crash.

Is the program running continuously for 2 months? If not, every start of the 
program can delete the log file, and start a new one. Will it be gigabytes long? 
That depends on your strategy of where to put the logging statements, which is a 
bit of an art. The size of the logs can also be reduced by using a compression 
or hash of the function names.

 > Another one was about your claim that segfaults are always useful.

And they are. Even if you have to resort to writing your own signal handler. 
They're always better than what I had to deal with debugging code on a machine 
without them.

When you do find the problem, I'd love to know what it was.