Skip to content
This repository was archived by the owner on Oct 12, 2022. It is now read-only.

Fix Issue 4587 - Assert exception should not allocate #1714

Closed
wants to merge 1 commit into from

Conversation

Darredevil
Copy link
Contributor

@Darredevil Darredevil commented Dec 14, 2016

@dlang-bot
Copy link
Contributor

Fix Bugzilla Description
4587 Assert exception should not allocate

@Darredevil
Copy link
Contributor Author

PS. I noticed there is another PR opened on this topic (#1710).
Will discuss this with @andralex before moving forward.

if( _assertHandler is null )
throw new AssertError( file, line );
import core.stdc.string : memcpy;
char[1024] buffer;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

declare this buffer just within the if

1024 is random and a magic number, you could be concrete with char[__traits(classInstanceSize, AssertError)] buffer;

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not to mention the alignment issue - I don't think there is guarantee that char[x] array is properly aligned.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not to also mention -- this is a local buffer which you are throwing outside the function. This results in corruption. Make it a static buffer.

if( _assertHandler is null ) {
enum size = __traits(classInstanceSize, AssertError);
memcpy(buffer.ptr, typeid(AssertError).initializer().ptr, size);
auto obj = cast(AssertError) buffer.ptr;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cast is ugly, could emplace be used?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

emplace is from Phobos, cannot be used.

@schveiguy
Copy link
Member

I think we should close this in favor of #1710

@andralex
Copy link
Member

andralex commented May 8, 2017

Yah, let's focus on #1710 and friends.

@andralex andralex closed this May 8, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants