delete[] with different type undefined behaviour?

Clash Royale CLAN TAG#URR8PPP

up vote
7
down vote

favorite

I am wondering if this is undefined behavior:

#include <stdint.h>

int main() 
 auto* p = new uint8_t[32];
 float* c = reinterpret_cast<float*>(p);
 delete c;

In the standard
there is

If not, the behavior is undefined. In the second alternative (delete array), the value of the operand of delete may be a null pointer value or a pointer value that resulted from a previous array new-expression.79 If not, the behavior is undefined. [ Note: this means that the syntax of the delete-expression must match the type of the object allocated by new, not the syntax of the new-expression. — end note ]

So interpreting the somewhat unclear phrase

this means that the syntax of the delete-expression must match the type of the object allocated by new, not the syntax of the new-expression

I can say the above is Undefined Behavior, correct?

c++

share|improve this question

edited 1 hour ago

asked 2 hours ago

Gabriel

3,12423051

add a comment | 

up vote
7
down vote

favorite

I am wondering if this is undefined behavior:

#include <stdint.h>

int main() 
 auto* p = new uint8_t[32];
 float* c = reinterpret_cast<float*>(p);
 delete c;

In the standard
there is

If not, the behavior is undefined. In the second alternative (delete array), the value of the operand of delete may be a null pointer value or a pointer value that resulted from a previous array new-expression.79 If not, the behavior is undefined. [ Note: this means that the syntax of the delete-expression must match the type of the object allocated by new, not the syntax of the new-expression. — end note ]

So interpreting the somewhat unclear phrase

this means that the syntax of the delete-expression must match the type of the object allocated by new, not the syntax of the new-expression

I can say the above is Undefined Behavior, correct?

c++

share|improve this question

edited 1 hour ago

asked 2 hours ago

Gabriel

3,12423051

add a comment | 

up vote
7
down vote

favorite

up vote
7
down vote

favorite

I am wondering if this is undefined behavior:

#include <stdint.h>

int main() 
 auto* p = new uint8_t[32];
 float* c = reinterpret_cast<float*>(p);
 delete c;

In the standard
there is

If not, the behavior is undefined. In the second alternative (delete array), the value of the operand of delete may be a null pointer value or a pointer value that resulted from a previous array new-expression.79 If not, the behavior is undefined. [ Note: this means that the syntax of the delete-expression must match the type of the object allocated by new, not the syntax of the new-expression. — end note ]

So interpreting the somewhat unclear phrase

this means that the syntax of the delete-expression must match the type of the object allocated by new, not the syntax of the new-expression

I can say the above is Undefined Behavior, correct?

c++

share|improve this question

edited 1 hour ago

asked 2 hours ago

Gabriel

3,12423051

I am wondering if this is undefined behavior:

#include <stdint.h>

int main() 
 auto* p = new uint8_t[32];
 float* c = reinterpret_cast<float*>(p);
 delete c;

In the standard
there is

If not, the behavior is undefined. In the second alternative (delete array), the value of the operand of delete may be a null pointer value or a pointer value that resulted from a previous array new-expression.79 If not, the behavior is undefined. [ Note: this means that the syntax of the delete-expression must match the type of the object allocated by new, not the syntax of the new-expression. — end note ]

So interpreting the somewhat unclear phrase

this means that the syntax of the delete-expression must match the type of the object allocated by new, not the syntax of the new-expression

I can say the above is Undefined Behavior, correct?

c++

c++

share|improve this question

edited 1 hour ago

asked 2 hours ago

Gabriel

3,12423051

share|improve this question

edited 1 hour ago

asked 2 hours ago

Gabriel

3,12423051

share|improve this question

share|improve this question

edited 1 hour ago

edited 1 hour ago

edited 1 hour ago

asked 2 hours ago

Gabriel

3,12423051

asked 2 hours ago

Gabriel

3,12423051

asked 2 hours ago

Gabriel

3,12423051

3,12423051

add a comment | 

add a comment | 

1 Answer
1

active

oldest

votes

up vote
9
down vote



accepted

Yes, the behaviour is undefined.

Unless related by polymorphism, the pointer passed to delete must be the same type as the one you get back from new. (The same applies to delete and new.)

share|improve this answer

answered 2 hours ago

Bathsheba

169k26238354

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Standard link that says this: [expr.delete]#3
  – Justin
  2 hours ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Should this be detectable by a sanitizer? I checked the snippet with -fsanitize=undefined,address, that didn't catch anything.
  – lubgr
  2 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I couldn't detect it as well with -fsanitize=leak,address (coliru...)
  – Gabriel
  2 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  well, on a number of platforms it might still generate legal code that's why AS wouldn't detect it. valgrind might not either. the issue is that in certain situation the value of c wouldn't be same as value of p, or that implementations tracks memory allocation in more discriminating way, that's where C++ standard comes with UB.
  – Swift - Friday Pie
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Interesting. Seems someone found my now deleted comment objectionable.
  – StoryTeller
  1 hour ago
  

  
  
  
  

 | 
show 3 more comments

Your Answer

StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52511763%2fdelete-with-different-type-undefined-behaviour%23new-answer', 'question_page');

);

Post as a guest

Name Email

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
9
down vote



accepted

Yes, the behaviour is undefined.

Unless related by polymorphism, the pointer passed to delete must be the same type as the one you get back from new. (The same applies to delete and new.)

share|improve this answer

answered 2 hours ago

Bathsheba

169k26238354

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Standard link that says this: [expr.delete]#3
  – Justin
  2 hours ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Should this be detectable by a sanitizer? I checked the snippet with -fsanitize=undefined,address, that didn't catch anything.
  – lubgr
  2 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I couldn't detect it as well with -fsanitize=leak,address (coliru...)
  – Gabriel
  2 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  well, on a number of platforms it might still generate legal code that's why AS wouldn't detect it. valgrind might not either. the issue is that in certain situation the value of c wouldn't be same as value of p, or that implementations tracks memory allocation in more discriminating way, that's where C++ standard comes with UB.
  – Swift - Friday Pie
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Interesting. Seems someone found my now deleted comment objectionable.
  – StoryTeller
  1 hour ago
  

  
  
  
  

 | 
show 3 more comments

up vote
9
down vote



accepted

Yes, the behaviour is undefined.

Unless related by polymorphism, the pointer passed to delete must be the same type as the one you get back from new. (The same applies to delete and new.)

share|improve this answer

answered 2 hours ago

Bathsheba

169k26238354

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Standard link that says this: [expr.delete]#3
  – Justin
  2 hours ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Should this be detectable by a sanitizer? I checked the snippet with -fsanitize=undefined,address, that didn't catch anything.
  – lubgr
  2 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I couldn't detect it as well with -fsanitize=leak,address (coliru...)
  – Gabriel
  2 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  well, on a number of platforms it might still generate legal code that's why AS wouldn't detect it. valgrind might not either. the issue is that in certain situation the value of c wouldn't be same as value of p, or that implementations tracks memory allocation in more discriminating way, that's where C++ standard comes with UB.
  – Swift - Friday Pie
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Interesting. Seems someone found my now deleted comment objectionable.
  – StoryTeller
  1 hour ago
  

  
  
  
  

 | 
show 3 more comments

up vote
9
down vote



accepted

up vote
9
down vote



accepted

Yes, the behaviour is undefined.

Unless related by polymorphism, the pointer passed to delete must be the same type as the one you get back from new. (The same applies to delete and new.)

share|improve this answer

answered 2 hours ago

Bathsheba

169k26238354

Yes, the behaviour is undefined.

Unless related by polymorphism, the pointer passed to delete must be the same type as the one you get back from new. (The same applies to delete and new.)

share|improve this answer

answered 2 hours ago

Bathsheba

169k26238354

share|improve this answer

share|improve this answer

answered 2 hours ago

Bathsheba

169k26238354

answered 2 hours ago

Bathsheba

169k26238354

answered 2 hours ago

Bathsheba

169k26238354

169k26238354

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Standard link that says this: [expr.delete]#3
  – Justin
  2 hours ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Should this be detectable by a sanitizer? I checked the snippet with -fsanitize=undefined,address, that didn't catch anything.
  – lubgr
  2 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I couldn't detect it as well with -fsanitize=leak,address (coliru...)
  – Gabriel
  2 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  well, on a number of platforms it might still generate legal code that's why AS wouldn't detect it. valgrind might not either. the issue is that in certain situation the value of c wouldn't be same as value of p, or that implementations tracks memory allocation in more discriminating way, that's where C++ standard comes with UB.
  – Swift - Friday Pie
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Interesting. Seems someone found my now deleted comment objectionable.
  – StoryTeller
  1 hour ago
  

  
  
  
  

 | 
show 3 more comments

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Standard link that says this: [expr.delete]#3
  – Justin
  2 hours ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Should this be detectable by a sanitizer? I checked the snippet with -fsanitize=undefined,address, that didn't catch anything.
  – lubgr
  2 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I couldn't detect it as well with -fsanitize=leak,address (coliru...)
  – Gabriel
  2 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  well, on a number of platforms it might still generate legal code that's why AS wouldn't detect it. valgrind might not either. the issue is that in certain situation the value of c wouldn't be same as value of p, or that implementations tracks memory allocation in more discriminating way, that's where C++ standard comes with UB.
  – Swift - Friday Pie
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Interesting. Seems someone found my now deleted comment objectionable.
  – StoryTeller
  1 hour ago
  

  
  
  
  

2

2

Standard link that says this: [expr.delete]#3
– Justin
2 hours ago

Standard link that says this: [expr.delete]#3
– Justin
2 hours ago

Should this be detectable by a sanitizer? I checked the snippet with -fsanitize=undefined,address, that didn't catch anything.
– lubgr
2 hours ago

Should this be detectable by a sanitizer? I checked the snippet with -fsanitize=undefined,address, that didn't catch anything.
– lubgr
2 hours ago

I couldn't detect it as well with -fsanitize=leak,address (coliru...)
– Gabriel
2 hours ago

I couldn't detect it as well with -fsanitize=leak,address (coliru...)
– Gabriel
2 hours ago

1

1

well, on a number of platforms it might still generate legal code that's why AS wouldn't detect it. valgrind might not either. the issue is that in certain situation the value of c wouldn't be same as value of p, or that implementations tracks memory allocation in more discriminating way, that's where C++ standard comes with UB.
– Swift - Friday Pie
1 hour ago

well, on a number of platforms it might still generate legal code that's why AS wouldn't detect it. valgrind might not either. the issue is that in certain situation the value of c wouldn't be same as value of p, or that implementations tracks memory allocation in more discriminating way, that's where C++ standard comes with UB.
– Swift - Friday Pie
1 hour ago

2

2

Interesting. Seems someone found my now deleted comment objectionable.
– StoryTeller
1 hour ago

Interesting. Seems someone found my now deleted comment objectionable.
– StoryTeller
1 hour ago

 | 
show 3 more comments

 

draft saved

draft discarded

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52511763%2fdelete-with-different-type-undefined-behaviour%23new-answer', 'question_page');

);

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Name Email

Name

Email

Name Email

Name

Email