Why static analysis is the way to go

[monkyyy]

On Friday, 29 May 2026 at 02:07:39 UTC, H. S. Teoh wrote:
> On Fri, May 29, 2026 at 01:11:02AM +0000, monkyyy via 
> Digitalmars-d wrote: [...]
>> Im asserting I write smaller programs then most, without 
>> @safe, without and debugger, using compiler bugs, void* 
>> whenever I want and I do not have memory management issues 
>> that rust and c++ smart pointers and allocators and gc debates 
>> claim is a hard problem. Because I do one thing: I push the 
>> blame to the datastructure where it belongs. When I call 
>> opIndex on my data structures I ussally make a small hack to 
>> make it return something; then I use that opIndex to make a 
>> range.
>
> Well, that explains a lot. :-D  If you mostly write 
> one-man-show small programs, none of these things are even an 
> issue.  Have a dangling pointer?  No problem, kill the process, 
> restart from clean slate.  Have a memory leak?  No problem, the 
> program will exit soon, OS will clean up for you.  Memory 
> corruption?  No problem, the worst case scenario is the program 
> crashes, OS cleans up, program restarts.
>
> I write a fair amount of small D programs as helper utilities, 
> and yeah for those I throw all care to the winds, allocate as 
> much as I want, GC will clean up.  Cast size_t to int, cast 
> void* to whatever*, doesn't matter.  Get the job done before 
> the boss fires you, good enough. Produce output before the 
> program corrupts itself into a bad state, good enough.
>
> But if you're writing a long-running daemon running in the 
> background, or an embedded system doing complex processing that 
> cannot afford to crash, because customer data must not be lost, 
> then these issues become big problems.  You cannot afford 
> memory corruption, because it might contain sensitive customer 
> data. You cannot afford dangling pointers, because some bot 
> online might exploit that to run arbitrary code and break into 
> your customer's corporate network.  You can't afford wasteful 
> memory usage, because you might run out of memory and crash in 
> the middle of customer's production operations and lose 
> customer data.
>
> We are not the same. :-D  lol
>


> gc
> os cleans up

https://monkyyy.itch.io/frut-gam3

video games are the hardest programming even if high frequency 
stock trading might be "more important" (stupid problems to have)

this was forced betterc shit and a not actually support platform

Compiler bugs were used to in-executable debugger

sub 200 lines of code for the main executable(lib code was of 
course much bigger) and im telling you there just isnt a memory 
leak in there for very very **dumb** reasons that I can and do 
explain to novices, if only anyone would listen

I struggle with big projects but line counts and stupid problems 
to have are not a measurement of success.