Is “sizeof new int;” undefined behavior?

Clash Royale CLAN TAG#URR8PPP

up vote
8
down vote

favorite

1

code:

#include<iostream>

using namespace std;

int main() 

 size_t i = sizeof new int;

 cout<<i;

In GCC compiler, working fine without any warning or error and printed output 8.

But, in clang compiler, I got the following warning:

warning: expression with side effects has no effect in an unevaluated context [-Wunevaluated-expression]
 size_t i = sizeof new int;

• Which one is true?


• Is sizeof new int; undefined behavior?

c++ c++11 g++ sizeof clang++

share|improve this question

edited 10 mins ago

doppelgreener

4,28663052

asked 52 mins ago

M.S Chaudhari

2,65711030

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  I see nothing wrong. This warning is more of a reminder, everything is well defined here.
  – YSC
  50 mins ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  This question is related to the C counterpart Why does sizeof(x++) not increment x?, but it is a bit clearer in C++.
  – Bartek Banachewicz
  37 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @BartekBanachewicz - a closer equivalent in C would be sizeof malloc(some_value) which would not call malloc() and, if performed after #include <stdlib.h>, would give a result equal to sizeof(void *).
  – Peter
  30 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  One could argue it's compiler caring about the WTF-factor.
  – luk32
  3 mins ago
  

  
  
  
  

add a comment | 

up vote
8
down vote

favorite

1

code:

#include<iostream>

using namespace std;

int main() 

 size_t i = sizeof new int;

 cout<<i;

In GCC compiler, working fine without any warning or error and printed output 8.

But, in clang compiler, I got the following warning:

warning: expression with side effects has no effect in an unevaluated context [-Wunevaluated-expression]
 size_t i = sizeof new int;

• Which one is true?


• Is sizeof new int; undefined behavior?

c++ c++11 g++ sizeof clang++

share|improve this question

edited 10 mins ago

doppelgreener

4,28663052

asked 52 mins ago

M.S Chaudhari

2,65711030

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  I see nothing wrong. This warning is more of a reminder, everything is well defined here.
  – YSC
  50 mins ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  This question is related to the C counterpart Why does sizeof(x++) not increment x?, but it is a bit clearer in C++.
  – Bartek Banachewicz
  37 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @BartekBanachewicz - a closer equivalent in C would be sizeof malloc(some_value) which would not call malloc() and, if performed after #include <stdlib.h>, would give a result equal to sizeof(void *).
  – Peter
  30 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  One could argue it's compiler caring about the WTF-factor.
  – luk32
  3 mins ago
  

  
  
  
  

add a comment | 

up vote
8
down vote

favorite

1

up vote
8
down vote

favorite

1

1

code:

#include<iostream>

using namespace std;

int main() 

 size_t i = sizeof new int;

 cout<<i;

In GCC compiler, working fine without any warning or error and printed output 8.

But, in clang compiler, I got the following warning:

warning: expression with side effects has no effect in an unevaluated context [-Wunevaluated-expression]
 size_t i = sizeof new int;

• Which one is true?


• Is sizeof new int; undefined behavior?

c++ c++11 g++ sizeof clang++

share|improve this question

edited 10 mins ago

doppelgreener

4,28663052

asked 52 mins ago

M.S Chaudhari

2,65711030

code:

#include<iostream>

using namespace std;

int main() 

 size_t i = sizeof new int;

 cout<<i;

In GCC compiler, working fine without any warning or error and printed output 8.

But, in clang compiler, I got the following warning:

warning: expression with side effects has no effect in an unevaluated context [-Wunevaluated-expression]
 size_t i = sizeof new int;

• Which one is true?


• Is sizeof new int; undefined behavior?

c++ c++11 g++ sizeof clang++

c++ c++11 g++ sizeof clang++

share|improve this question

edited 10 mins ago

doppelgreener

4,28663052

asked 52 mins ago

M.S Chaudhari

2,65711030

share|improve this question

edited 10 mins ago

doppelgreener

4,28663052

asked 52 mins ago

M.S Chaudhari

2,65711030

share|improve this question

share|improve this question

edited 10 mins ago

doppelgreener

4,28663052

edited 10 mins ago

doppelgreener

4,28663052

edited 10 mins ago

doppelgreener

4,28663052

4,28663052

asked 52 mins ago

M.S Chaudhari

2,65711030

asked 52 mins ago

M.S Chaudhari

2,65711030

asked 52 mins ago

M.S Chaudhari

2,65711030

2,65711030

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  I see nothing wrong. This warning is more of a reminder, everything is well defined here.
  – YSC
  50 mins ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  This question is related to the C counterpart Why does sizeof(x++) not increment x?, but it is a bit clearer in C++.
  – Bartek Banachewicz
  37 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @BartekBanachewicz - a closer equivalent in C would be sizeof malloc(some_value) which would not call malloc() and, if performed after #include <stdlib.h>, would give a result equal to sizeof(void *).
  – Peter
  30 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  One could argue it's compiler caring about the WTF-factor.
  – luk32
  3 mins ago
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  I see nothing wrong. This warning is more of a reminder, everything is well defined here.
  – YSC
  50 mins ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  This question is related to the C counterpart Why does sizeof(x++) not increment x?, but it is a bit clearer in C++.
  – Bartek Banachewicz
  37 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @BartekBanachewicz - a closer equivalent in C would be sizeof malloc(some_value) which would not call malloc() and, if performed after #include <stdlib.h>, would give a result equal to sizeof(void *).
  – Peter
  30 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  One could argue it's compiler caring about the WTF-factor.
  – luk32
  3 mins ago
  

  
  
  
  

2

2

I see nothing wrong. This warning is more of a reminder, everything is well defined here.
– YSC
50 mins ago

I see nothing wrong. This warning is more of a reminder, everything is well defined here.
– YSC
50 mins ago

This question is related to the C counterpart Why does sizeof(x++) not increment x?, but it is a bit clearer in C++.
– Bartek Banachewicz
37 mins ago

This question is related to the C counterpart Why does sizeof(x++) not increment x?, but it is a bit clearer in C++.
– Bartek Banachewicz
37 mins ago

@BartekBanachewicz - a closer equivalent in C would be sizeof malloc(some_value) which would not call malloc() and, if performed after #include <stdlib.h>, would give a result equal to sizeof(void *).
– Peter
30 mins ago

@BartekBanachewicz - a closer equivalent in C would be sizeof malloc(some_value) which would not call malloc() and, if performed after #include <stdlib.h>, would give a result equal to sizeof(void *).
– Peter
30 mins ago

One could argue it's compiler caring about the WTF-factor.
– luk32
3 mins ago

One could argue it's compiler caring about the WTF-factor.
– luk32
3 mins ago

add a comment | 

2 Answers
2

active

oldest

votes

up vote
20
down vote



accepted

The warning doesn't state that it's UB; it merely says that the context of use, namely sizeof, won't trigger the side effects (which in case of new is allocating memory).

[expr.sizeof]
The sizeof operator yields the number of bytes occupied by a non-potentially-overlapping object of the type of its operand. The operand is either an expression, which is an unevaluated operand ([expr.prop]), or a parenthesized type-id.

The standard also helpfully explains what that means:

[expr.context] (...) An unevaluated operand is not evaluated.

It's a fine, although a weird way to write sizeof(int*).

share|improve this answer

answered 50 mins ago

Bartek Banachewicz

28.9k460103

add a comment | 

up vote
5
down vote

new operator returns pointer to the allocated memory. So size_t i = sizeof new int; will not cause undefined behaviour.

Warning is legit and only warns about the effect of side-effect on the operand and that's because operands of sizeof is not evaluated.

For example:

int i = 1;
std::cout << i << 'n'; // Prints 1
size_t size = sizeof(i++); // i++ will not be evaluated
std::cout << i << 'n'; // Prints 1

share|improve this answer

edited 43 mins ago

answered 49 mins ago

haccks

84.2k20123215

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Curiously, it's easy to make i++ be evaluated: cpp.sh/9774o
  – Dan M.
  28 mins ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @DanM.; int[i++] will be evaluated at runtime, exception for variable length arrays. Note that c++ doesn't allow VLA but GCC and clang provide it as an extension.
  – haccks
  15 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  yeah I know. Just a peculiar gotcha. Same with int(*)[i++] being either evaluated or not depending on the implementation.
  – Dan M.
  8 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @DanM. is that due to ambiguity in the spec, or compiler bugs? I'm inclined to suspect the latter.
  – Max Barraclough
  2 mins ago
  

  
  
  
  

add a comment | 

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%2f52624526%2fis-sizeof-new-int-undefined-behavior%23new-answer', 'question_page');

);

Post as a guest

Name Email

2 Answers
2

active

oldest

votes

2 Answers
2

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
20
down vote



accepted

The warning doesn't state that it's UB; it merely says that the context of use, namely sizeof, won't trigger the side effects (which in case of new is allocating memory).

[expr.sizeof]
The sizeof operator yields the number of bytes occupied by a non-potentially-overlapping object of the type of its operand. The operand is either an expression, which is an unevaluated operand ([expr.prop]), or a parenthesized type-id.

The standard also helpfully explains what that means:

[expr.context] (...) An unevaluated operand is not evaluated.

It's a fine, although a weird way to write sizeof(int*).

share|improve this answer

answered 50 mins ago

Bartek Banachewicz

28.9k460103

add a comment | 

up vote
20
down vote



accepted

The warning doesn't state that it's UB; it merely says that the context of use, namely sizeof, won't trigger the side effects (which in case of new is allocating memory).

[expr.sizeof]
The sizeof operator yields the number of bytes occupied by a non-potentially-overlapping object of the type of its operand. The operand is either an expression, which is an unevaluated operand ([expr.prop]), or a parenthesized type-id.

The standard also helpfully explains what that means:

[expr.context] (...) An unevaluated operand is not evaluated.

It's a fine, although a weird way to write sizeof(int*).

share|improve this answer

answered 50 mins ago

Bartek Banachewicz

28.9k460103

add a comment | 

up vote
20
down vote



accepted

up vote
20
down vote



accepted

The warning doesn't state that it's UB; it merely says that the context of use, namely sizeof, won't trigger the side effects (which in case of new is allocating memory).

[expr.sizeof]
The sizeof operator yields the number of bytes occupied by a non-potentially-overlapping object of the type of its operand. The operand is either an expression, which is an unevaluated operand ([expr.prop]), or a parenthesized type-id.

The standard also helpfully explains what that means:

[expr.context] (...) An unevaluated operand is not evaluated.

It's a fine, although a weird way to write sizeof(int*).

share|improve this answer

answered 50 mins ago

Bartek Banachewicz

28.9k460103

The warning doesn't state that it's UB; it merely says that the context of use, namely sizeof, won't trigger the side effects (which in case of new is allocating memory).

[expr.sizeof]
The sizeof operator yields the number of bytes occupied by a non-potentially-overlapping object of the type of its operand. The operand is either an expression, which is an unevaluated operand ([expr.prop]), or a parenthesized type-id.

The standard also helpfully explains what that means:

[expr.context] (...) An unevaluated operand is not evaluated.

It's a fine, although a weird way to write sizeof(int*).

share|improve this answer

answered 50 mins ago

Bartek Banachewicz

28.9k460103

share|improve this answer

share|improve this answer

answered 50 mins ago

Bartek Banachewicz

28.9k460103

answered 50 mins ago

Bartek Banachewicz

28.9k460103

answered 50 mins ago

Bartek Banachewicz

28.9k460103

28.9k460103

add a comment | 

add a comment | 

up vote
5
down vote

new operator returns pointer to the allocated memory. So size_t i = sizeof new int; will not cause undefined behaviour.

Warning is legit and only warns about the effect of side-effect on the operand and that's because operands of sizeof is not evaluated.

For example:

int i = 1;
std::cout << i << 'n'; // Prints 1
size_t size = sizeof(i++); // i++ will not be evaluated
std::cout << i << 'n'; // Prints 1

share|improve this answer

edited 43 mins ago

answered 49 mins ago

haccks

84.2k20123215

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Curiously, it's easy to make i++ be evaluated: cpp.sh/9774o
  – Dan M.
  28 mins ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @DanM.; int[i++] will be evaluated at runtime, exception for variable length arrays. Note that c++ doesn't allow VLA but GCC and clang provide it as an extension.
  – haccks
  15 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  yeah I know. Just a peculiar gotcha. Same with int(*)[i++] being either evaluated or not depending on the implementation.
  – Dan M.
  8 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @DanM. is that due to ambiguity in the spec, or compiler bugs? I'm inclined to suspect the latter.
  – Max Barraclough
  2 mins ago
  

  
  
  
  

add a comment | 

up vote
5
down vote

new operator returns pointer to the allocated memory. So size_t i = sizeof new int; will not cause undefined behaviour.

Warning is legit and only warns about the effect of side-effect on the operand and that's because operands of sizeof is not evaluated.

For example:

int i = 1;
std::cout << i << 'n'; // Prints 1
size_t size = sizeof(i++); // i++ will not be evaluated
std::cout << i << 'n'; // Prints 1

share|improve this answer

edited 43 mins ago

answered 49 mins ago

haccks

84.2k20123215

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Curiously, it's easy to make i++ be evaluated: cpp.sh/9774o
  – Dan M.
  28 mins ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @DanM.; int[i++] will be evaluated at runtime, exception for variable length arrays. Note that c++ doesn't allow VLA but GCC and clang provide it as an extension.
  – haccks
  15 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  yeah I know. Just a peculiar gotcha. Same with int(*)[i++] being either evaluated or not depending on the implementation.
  – Dan M.
  8 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @DanM. is that due to ambiguity in the spec, or compiler bugs? I'm inclined to suspect the latter.
  – Max Barraclough
  2 mins ago
  

  
  
  
  

add a comment | 

up vote
5
down vote

up vote
5
down vote

new operator returns pointer to the allocated memory. So size_t i = sizeof new int; will not cause undefined behaviour.

Warning is legit and only warns about the effect of side-effect on the operand and that's because operands of sizeof is not evaluated.

For example:

int i = 1;
std::cout << i << 'n'; // Prints 1
size_t size = sizeof(i++); // i++ will not be evaluated
std::cout << i << 'n'; // Prints 1

share|improve this answer

edited 43 mins ago

answered 49 mins ago

haccks

84.2k20123215

new operator returns pointer to the allocated memory. So size_t i = sizeof new int; will not cause undefined behaviour.

Warning is legit and only warns about the effect of side-effect on the operand and that's because operands of sizeof is not evaluated.

For example:

int i = 1;
std::cout << i << 'n'; // Prints 1
size_t size = sizeof(i++); // i++ will not be evaluated
std::cout << i << 'n'; // Prints 1

share|improve this answer

edited 43 mins ago

answered 49 mins ago

haccks

84.2k20123215

share|improve this answer

share|improve this answer

edited 43 mins ago

edited 43 mins ago

edited 43 mins ago

answered 49 mins ago

haccks

84.2k20123215

answered 49 mins ago

haccks

84.2k20123215

answered 49 mins ago

haccks

84.2k20123215

84.2k20123215

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Curiously, it's easy to make i++ be evaluated: cpp.sh/9774o
  – Dan M.
  28 mins ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @DanM.; int[i++] will be evaluated at runtime, exception for variable length arrays. Note that c++ doesn't allow VLA but GCC and clang provide it as an extension.
  – haccks
  15 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  yeah I know. Just a peculiar gotcha. Same with int(*)[i++] being either evaluated or not depending on the implementation.
  – Dan M.
  8 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @DanM. is that due to ambiguity in the spec, or compiler bugs? I'm inclined to suspect the latter.
  – Max Barraclough
  2 mins ago
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Curiously, it's easy to make i++ be evaluated: cpp.sh/9774o
  – Dan M.
  28 mins ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @DanM.; int[i++] will be evaluated at runtime, exception for variable length arrays. Note that c++ doesn't allow VLA but GCC and clang provide it as an extension.
  – haccks
  15 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  yeah I know. Just a peculiar gotcha. Same with int(*)[i++] being either evaluated or not depending on the implementation.
  – Dan M.
  8 mins ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @DanM. is that due to ambiguity in the spec, or compiler bugs? I'm inclined to suspect the latter.
  – Max Barraclough
  2 mins ago
  

  
  
  
  

2

2

Curiously, it's easy to make i++ be evaluated: cpp.sh/9774o
– Dan M.
28 mins ago

Curiously, it's easy to make i++ be evaluated: cpp.sh/9774o
– Dan M.
28 mins ago

1

1

@DanM.; int[i++] will be evaluated at runtime, exception for variable length arrays. Note that c++ doesn't allow VLA but GCC and clang provide it as an extension.
– haccks
15 mins ago

@DanM.; int[i++] will be evaluated at runtime, exception for variable length arrays. Note that c++ doesn't allow VLA but GCC and clang provide it as an extension.
– haccks
15 mins ago

yeah I know. Just a peculiar gotcha. Same with int(*)[i++] being either evaluated or not depending on the implementation.
– Dan M.
8 mins ago

yeah I know. Just a peculiar gotcha. Same with int(*)[i++] being either evaluated or not depending on the implementation.
– Dan M.
8 mins ago

@DanM. is that due to ambiguity in the spec, or compiler bugs? I'm inclined to suspect the latter.
– Max Barraclough
2 mins ago

@DanM. is that due to ambiguity in the spec, or compiler bugs? I'm inclined to suspect the latter.
– Max Barraclough
2 mins ago

add a comment | 

 

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%2f52624526%2fis-sizeof-new-int-undefined-behavior%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