[OT] OT: Null checks.

[Walter Bright]

On 5/3/2025 8:48 PM, Timon Gehr wrote:
> This is not only the case in C. Translate the example to D and compile with LDC 
> with optimizations enabled. You will most likely see zero segfaults.

I replied to that in the other post.


> On an somewhat related note: in D you can currently create invalid non-null 
> pointers in `@safe` code by exploiting the lack of checks.

D relies on the null dereference not being "optimized away". Maybe there's a 
switch for that on ldc, there should be if there isn't one.


> All I am seeing is that sometimes user's programs close and they are not giving 
> me any further information because they don't really know how to use a computer 
> and it happens infrequently enough that they don't care enough to try to figure 
> out how to help me out. This may be a null dereference, or it could be something 
> else. Maybe it even prints a stack trace on Windows, but the console window 
> closes on them immediately or something. Who knows what actually is happening. I 
> am not seeing this on my machine...

Such can be pretty tough to figure out. It could be a bug in your code, it could 
be a codegen bug, it could a bug in the library, etc. Maybe try sending them an 
unoptimized build? maybe add a signal handler that writes the diagnostic 
information to a file before exiting?


> I can probably try to set up some other way to debug that then gets flagged as 
> malware even harder. However, none of this is necessary in the first place. If 
> my `scope(exit)` ran they would be able to immediately provide all the info I 
> need, as was the case with a couple thrown Exceptions and Errors in the past.

I thought you wrote that scope(exit) was catching null pointer exceptions.


> Well congrats, seems your bugs were reproducible on your own machine and at a 
> frequency of more than once every couple of months.

I've also had to remotely debug buildkite failures. I've done it by adding 
strategic printfs to generate a log of the path through the compiler.

I've also done things by trying out the problem on another operating system, or 
different codegen switches. This can give helpful information. Anything you can 
do to vary the environment to see what might trigger it.

> I don't even know if the 
> crashes are my fault or not. Maybe they even happen in some dependency, which I 
> would know if D's error handling was more useful.

I find the stack trace useful enough.


> AFAIU the default druntime ships with `-release`.

See the -checkaction= switch?


> It's not useless for everything, it's just useless for some things. Your 
> anecdotes are unfortunately not universal and also things changed.

It only has to work on platforms D supports, not every computer ever made. C has 
made some tragic decisions to support every computer ever made, resulting in 
some awful "portable" code that doesn't actually work on those nutburger 
machines. For one sad case, 16 bit Windows was written with portability to 32 
bits in mind. When 32 bit machines finally arrived, Microsoft had a big problem 
that despite writing "portable" code, they'd made all the wrong decisions about 
what parts need to be adapted.

I've seen another case where char sizes were 32 bits. Of course, no C program 
would work on it without being recoded, in spite of all the portability 
misfeatures in C. C character sets aren't portable either, as RADIX50 won't 
work. Nobody ever used trigraphs and digraphs outside of test suites and 
Obfuscated C Contest entries.

>> P.P.S. `scope(failure)` is not intended for catching `Error`, although it 
>> does. There's a PR to fix it to only catch `Exception`, but that failed in the 
>> test suite. 
> 
> This is heart-shattering news. If this ever gets pulled without any option to 
> revert I will no longer be able to justify using the official D releases for 
> anything.

I had no idea anyone was using it for that purpose. I guess I can't change that :-)