Menu
Search

Forums

Forum Index

9 hours ago
Gravatar of KagaminPosted by Kagamin
in reply to Walter Bright		Reply
Kagamin
Gravatar of Kagamin
Posted in reply to Walter Bright


Reply
And to call assertHandler the code should call onAssertErrorMsg to mirror dmd behavior.
9 hours ago
Gravatar of KagaminPosted by Kagamin
in reply to Kagamin		Reply
Kagamin
Gravatar of Kagamin
Posted in reply to Kagamin


Reply

like this

private void _enforceNoOverlap(const char[] action,
    uintptr_t ptr1, uintptr_t ptr2, const size_t bytes)
{
    import core.exception;
    const d = ptr1 > ptr2 ? ptr1 - ptr2 : ptr2 - ptr1;
    if (d >= bytes)
        return;
    const overlappedBytes = bytes - d;

    UnsignedStringBuf tmpBuff = void;
    string msg = "Overlapping arrays in ";
    msg ~= action;
    msg ~= ": ";
    msg ~= overlappedBytes.unsignedToTempString(tmpBuff, 10);
    msg ~= " byte(s) overlap of ";
    msg ~= bytes.unsignedToTempString(tmpBuff, 10);
    onAssertErrorMsg(__FILE__,__LINE__,msg);
    assert(0, msg);
}
9 hours ago
Gravatar of KagaminPosted by Kagamin
in reply to Walter Bright		Reply
Kagamin
Gravatar of Kagamin
Posted in reply to Walter Bright


Reply

On Tuesday, 6 May 2025 at 06:11:29 UTC, Walter Bright wrote:

>

D is set up so if you throw an Exception, then destructors will run as the stack unwinds. But if you throw an Error, you can catch it but the destructors don't run.

The reason is that Error means the program has entered an invalid state. Nothing in the program can be trusted any more. The program should do as little as possible to close down gracefully.

The template std.exception.enforce works like assert, but throws an Exception instead.

Or do you mean _enforceNoOverlap should be renamed to _assertNoOverlap?

8 hours ago
Gravatar of KagaminPosted by Kagamin
in reply to Walter Bright		Reply
Kagamin
Gravatar of Kagamin
Posted in reply to Walter Bright


Reply

On Tuesday, 6 May 2025 at 06:11:29 UTC, Walter Bright wrote:

>

What you can do is override the default assert behavior by inserting your own assert handler by calling core.exception.assertHandler(). Be sure to set -checkaction=D

Then you can have assert() behave however you want.

https://github.com/dlang/dlang.org/pull/2702

>

To have a nice message, use checkaction to change it to what is desired.

As I understand, these functions are checkaction implementation, e.g. dmd doesn't call them by default.

8 hours ago
Gravatar of Walter BrightPosted by Walter Bright
in reply to Timon Gehr		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Timon Gehr


Reply
Good that you checked. Go ahead and revert it.
8 hours ago
Gravatar of Walter BrightPosted by Walter Bright
in reply to Kagamin		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Kagamin


Reply
I don't understand your comment. The assert can be changed to whatever you want by setting the assert handler.
8 hours ago
Gravatar of Walter BrightPosted by Walter Bright
in reply to Timon Gehr		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Timon Gehr


Reply
On 5/5/2025 8:12 PM, Timon Gehr wrote:
> druntime is built with that switch, so even in debug builds you will get invalid instruction errors. We have to fix this.

Then revert it back to throwing an Error.
8 hours ago
Gravatar of Walter BrightPosted by Walter Bright
in reply to Max Samukha		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Max Samukha


Reply
On 5/5/2025 11:30 PM, Max Samukha wrote:
> Why would you assume that the code that doesn't rely on the GC is in a working state?


You're right, there's no guarantee whatsoever that *any* of the code or data is in a valid state.

But it's much less code, so correspondingly much less likely to have been corrupted.

I prefer the "Go Directly To Jail, Do Not Pass Go, Do Not Collect $200" method of dealing with crashed programs, hence my preference for executing an invalid instruction. That comes from my experience with avionics in aircraft, where when an invalid state is detected the faulty box is immediately electrically isolated from the rest of the airplane, and the backup is engaged.

But, of course if you want logging, you'll have to risk it.

I would not enable such logging in any critical software, but it seems I am the only such person.
7 hours ago
Gravatar of Richard (Rikki) Andrew CattermolePosted by Richard (Rikki) Andrew Cattermole
in reply to Walter Bright		Reply
Richard (Rikki) Andrew Cattermole
Gravatar of Richard (Rikki) Andrew Cattermole
Posted in reply to Walter Bright


Reply
On 06/05/2025 8:03 PM, Walter Bright wrote:
> But, of course if you want logging, you'll have to risk it.
> 
> I would not enable such logging in any critical software, but it seems I am the only such person.

This is why its so important to switch over to calling the global functions like assert handler does.

People can configure it to do whatever they want, we don't have to have a default that is anything but instant crash.

But it does mean that the compiler has to be generating the calls.
41 minutes ago
Gravatar of Timon GehrPosted by Timon Gehr
in reply to Walter Bright		Reply
Timon Gehr
Gravatar of Timon Gehr
Posted in reply to Walter Bright


Reply
On 5/6/25 09:48, Walter Bright wrote:
> I don't understand your comment. The assert can be changed to whatever you want by setting the assert handler.

- There are `assert(0)` in druntime.
- Druntime/Phobos ship as `-release` build.

Therefore, setting the assert handler will do nothing, even if you configure checkaction to call it in your own project.


Kagamin is saying:

- The implementation of checkaction itself is where you added the `assert(0)`. (!)

I.e., even if you configure your project not to hard-crash, the function that is supposed to implement the soft crash will itself hard-crash.

- DMD does not call this function by default.

But LDC does. So you get invalid instruction errors in LDC debug builds.
« First   ‹ Prev
1 2 3 4 5 6 7
Next ›   Last »