[OT] OT: Null checks.

[Timon Gehr]

On 5/6/25 01:49, Walter Bright wrote:
>  ...
>  > 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.
> ...

I am perfectly content with it throwing an assert error and unwinding 
the stack. This is just not what druntime will do in the default build 
that ships with the compiler.

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

I am sure that does not work with the default build of druntime, when 
the assert(0) is also in druntime.

>  > 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.
> ...

Sure. You are making my point for me though, this amount of effort is 
vastly disproportionate to address an issue that is a) likely to 
originate in druntime and b) extremely uncommon and c) most likely 
trivial to deal with in some competing languages.

>  > 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.
> ...

Well, I think I already granted that they are better than just letting 
the program run with memory corruption.

I just wish everyone would refrain from actively putting invalid 
instructions and segfaults into druntime in the future. They are not 
_that_ useful and there are vastly more useful alternatives. x)

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

I'll let you know. Not likely to happen very soon though.

I also still have to reduce a similar heisenbug I had where Phobos 
`sort` sometimes corrupted the data it was sorting.