On Wednesday, 2 July 2025 at 16:54:54 UTC, monkyyy wrote:
> On Wednesday, 2 July 2025 at 16:51:40 UTC, kdevel wrote:
>> On Wednesday, 2 July 2025 at 08:11:44 UTC, Walter Bright wrote:
>>> On 6/30/2025 2:18 PM, Sebastiaan Koppe wrote:
>>>> Just know that the idea of exiting directly when something asserts on the pretense that continueing makes things worse breaks down in multi-threaded programs.
>>>
>>> An assert tripping means that you've got a bug in the program, and the program has entered an unanticipated, unknown state.
>>
>> This program
>>
>>    void main ()
>>    {
>>       assert (false);
>>    }
>>
>> is a valid D program which is free of bugs and without any
>> "unanticipated, unknown" state.
>>
>> Do you agree?
>
> Nah, clearly this wouldnt pass boeings standards

In release mode it does.

On Thursday, 3 July 2025 at 10:19:18 UTC, Paolo Invernizzi wrote:
> What's preventing you to have debugging information in remote server environment without  physical access the device?
>
> We are not in the 80 anymore, but even in the 80 ...
>
> /P

I can't hook debuggers up to code running on a remote server that somebody else owns in a DC hundreds of miles away. Therefore the only debugging data available is stack traces. If the language prevents the emission of stack traces then I get ... absolutely nothing.

But why can't I just run my code on a VM with debuggers on it?

Because direct remote access to production machines is strictly forbidden under most security and even regulatory regimes. Ironically, this is because direct remote access to production machines is a FAR larger security threat than a theoretical stack-corruption attack. All I need to get access is to subvert the right human, which is a far less complex attack than subverting the myriad stack protections. And is why most modern attacks focus on humans and not technology.

All of this was covered in my yearly Security Training at Microsoft as far back as 2015. These are well known limitations in corporate IT security. Oh, and I spent about a year of my time at Microsoft doing security and compliance work.

Having direct remote access to production is often a strict legal liability (which means that if the investigation discovers that you allow it, then it is presumed as a matter of law that the breach came from that route and you'll be found guilty right then and there), so you're never going to find a serious business willing to allow it.

At Microsoft, to access production I had to fill out a form and sign it to get access to production. Then I used a specially modified laptop with no custom software installed on it and all the input ports physically disabled that was hooked up to a separate network to gain access. If I needed a tool on the production machine I had to specifically request it from IT and wait for them to install it, I was not allowed to install anything on my own (which could be malware of course)

Needless to say, my manager made us spend an enormous amount of our time making sure that we never needed access to production. The one time I did need production access was ironically because the extensive logging infrastructure we built crashed with no information recorded. So if I seem a bit animated about his topic, it's because I've been the guy whose had to resolve a problem under the exact conditions that we're proposing here.

This is exactly the kind of choice that gets your tech banned from corporate usage.

On 7/3/2025 12:21 AM, Adam Wilson wrote:
> It is an absolute non-negotiable business requirement that I be able to get debugging information out of the server without physical access to the device. If you won't deliver the logging data, corrupted or not, on an assert, then no business can justify using D in production.

I did mention that logging the error before terminating the process was acceptable. My point is that recovering is not acceptable.