What's the behavior of an uninitialized variable used as its own initializer?

I noticed just now that the following code can be compiled with clang/gcc/clang++/g++, using c99, c11, c++11 standards.

int main(void) {

    int i = i;

}

and even with -Wall -Wextra, none of the compilers even reports warnings.

By modifying the code to int i = i + 1; and with -Wall, they may report:

why.c:2:13: warning: variable 'i' is uninitialized when used within its own initialization [-Wuninitialized]

    int i = i + 1;

        ~   ^

1 warning generated.

My questions:

Why is this even allowed by compilers?

What does the C/C++ standards say about this? Specifically, what's the behavior of this? UB or implementation dependent?

edited Jan 15 at 15:46

Lundin

110k17161265

asked Jan 15 at 14:03

Hongxu Chen

2,6322967

2

There is nothing "even" in -Wall -Wextra. That's about the bare minimum in warnings. See this answer of mine to an older question about -Wall...

– DevSolar
Jan 15 at 14:09

1

-Wall is enough for me to get a warning for gcc

– Kevin
Jan 15 at 14:12

2

Duplicate: Why does the compiler allow initializing a variable with itself?. However, the answers there are not very good. So lets leave this open for now and see if something better comes up. Then we can close the linked post instead.

– Lundin
Jan 15 at 14:52

2

I improved the title and will mop up some old, bad duplicates, since the answers posted here so far are already better than those posted for the dupe questions.

– Lundin
Jan 15 at 15:48

1

The C++ part is a duplicate of stackoverflow.com/q/14935722/5376789

– xskxzr
Jan 15 at 16:07

|
show 5 more comments

I noticed just now that the following code can be compiled with clang/gcc/clang++/g++, using c99, c11, c++11 standards.

int main(void) {

    int i = i;

}

and even with -Wall -Wextra, none of the compilers even reports warnings.

By modifying the code to int i = i + 1; and with -Wall, they may report:

why.c:2:13: warning: variable 'i' is uninitialized when used within its own initialization [-Wuninitialized]

    int i = i + 1;

        ~   ^

1 warning generated.

My questions:

Why is this even allowed by compilers?

What does the C/C++ standards say about this? Specifically, what's the behavior of this? UB or implementation dependent?

edited Jan 15 at 15:46

Lundin

110k17161265

asked Jan 15 at 14:03

Hongxu Chen

2,6322967

2

There is nothing "even" in -Wall -Wextra. That's about the bare minimum in warnings. See this answer of mine to an older question about -Wall...

– DevSolar
Jan 15 at 14:09

1

-Wall is enough for me to get a warning for gcc

– Kevin
Jan 15 at 14:12

2

Duplicate: Why does the compiler allow initializing a variable with itself?. However, the answers there are not very good. So lets leave this open for now and see if something better comes up. Then we can close the linked post instead.

– Lundin
Jan 15 at 14:52

2

I improved the title and will mop up some old, bad duplicates, since the answers posted here so far are already better than those posted for the dupe questions.

– Lundin
Jan 15 at 15:48

1

The C++ part is a duplicate of stackoverflow.com/q/14935722/5376789

– xskxzr
Jan 15 at 16:07

|
show 5 more comments

I noticed just now that the following code can be compiled with clang/gcc/clang++/g++, using c99, c11, c++11 standards.

int main(void) {

    int i = i;

}

and even with -Wall -Wextra, none of the compilers even reports warnings.

By modifying the code to int i = i + 1; and with -Wall, they may report:

why.c:2:13: warning: variable 'i' is uninitialized when used within its own initialization [-Wuninitialized]

    int i = i + 1;

        ~   ^

1 warning generated.

My questions:

Why is this even allowed by compilers?

What does the C/C++ standards say about this? Specifically, what's the behavior of this? UB or implementation dependent?

edited Jan 15 at 15:46

Lundin

110k17161265

asked Jan 15 at 14:03

Hongxu Chen

2,6322967

I noticed just now that the following code can be compiled with clang/gcc/clang++/g++, using c99, c11, c++11 standards.

int main(void) {

    int i = i;

}

and even with -Wall -Wextra, none of the compilers even reports warnings.

By modifying the code to int i = i + 1; and with -Wall, they may report:

why.c:2:13: warning: variable 'i' is uninitialized when used within its own initialization [-Wuninitialized]

    int i = i + 1;

        ~   ^

1 warning generated.

My questions:

Why is this even allowed by compilers?

What does the C/C++ standards say about this? Specifically, what's the behavior of this? UB or implementation dependent?

c++ c initialization language-lawyer

edited Jan 15 at 15:46

Lundin

110k17161265

asked Jan 15 at 14:03

Hongxu Chen

2,6322967

edited Jan 15 at 15:46

Lundin

110k17161265

asked Jan 15 at 14:03

Hongxu Chen

2,6322967

edited Jan 15 at 15:46

Lundin

110k17161265

edited Jan 15 at 15:46

Lundin

110k17161265

edited Jan 15 at 15:46

Lundin

110k17161265

asked Jan 15 at 14:03

Hongxu Chen

2,6322967

asked Jan 15 at 14:03

Hongxu Chen

2,6322967

asked Jan 15 at 14:03

Hongxu Chen

2,6322967

2

There is nothing "even" in -Wall -Wextra. That's about the bare minimum in warnings. See this answer of mine to an older question about -Wall...

– DevSolar
Jan 15 at 14:09

1

-Wall is enough for me to get a warning for gcc

– Kevin
Jan 15 at 14:12

2

Duplicate: Why does the compiler allow initializing a variable with itself?. However, the answers there are not very good. So lets leave this open for now and see if something better comes up. Then we can close the linked post instead.

– Lundin
Jan 15 at 14:52

2

I improved the title and will mop up some old, bad duplicates, since the answers posted here so far are already better than those posted for the dupe questions.

– Lundin
Jan 15 at 15:48

1

The C++ part is a duplicate of stackoverflow.com/q/14935722/5376789

– xskxzr
Jan 15 at 16:07

|
show 5 more comments

2

There is nothing "even" in -Wall -Wextra. That's about the bare minimum in warnings. See this answer of mine to an older question about -Wall...

– DevSolar
Jan 15 at 14:09

1

-Wall is enough for me to get a warning for gcc

– Kevin
Jan 15 at 14:12

2

Duplicate: Why does the compiler allow initializing a variable with itself?. However, the answers there are not very good. So lets leave this open for now and see if something better comes up. Then we can close the linked post instead.

– Lundin
Jan 15 at 14:52

2

I improved the title and will mop up some old, bad duplicates, since the answers posted here so far are already better than those posted for the dupe questions.

– Lundin
Jan 15 at 15:48

1

The C++ part is a duplicate of stackoverflow.com/q/14935722/5376789

– xskxzr
Jan 15 at 16:07

There is nothing "even" in -Wall -Wextra. That's about the bare minimum in warnings. See this answer of mine to an older question about -Wall...

– DevSolar
Jan 15 at 14:09

-Wall is enough for me to get a warning for gcc

– Kevin
Jan 15 at 14:12

Duplicate: Why does the compiler allow initializing a variable with itself?. However, the answers there are not very good. So lets leave this open for now and see if something better comes up. Then we can close the linked post instead.

– Lundin
Jan 15 at 14:52

I improved the title and will mop up some old, bad duplicates, since the answers posted here so far are already better than those posted for the dupe questions.

– Lundin
Jan 15 at 15:48

The C++ part is a duplicate of stackoverflow.com/q/14935722/5376789

– xskxzr
Jan 15 at 16:07

|
show 5 more comments

3 Answers
3

active

oldest

votes

Because i is uninitialized when use to initialize itself, it has an indeterminate value at that time. An indeterminate value can be either an unspecified value or a trap representation.

If your implementation supports padding bits in integer types and if the indeterminate value in question happens to be a trap representation, then using it results in undefined behavior.

If your implementation does not have padding in integers, then the value is simply unspecified and there is no undefined behavior.

EDIT:

To elaborate further, the behavior can still be undefined if i never has its address taken at some point. This is detailed in section 6.3.2.1p2 of the C11 standard:

If the lvalue designates an object of automatic storage
duration that could have been declared with the register storage
class (never had its address taken), and that object is uninitialized
(not declared with an initializer and no assignment to it
has been performed prior to use), the behavior is undefined.

So if you never take the address of i, then you have undefined behavior. Otherwise, the statements above apply.

edited Jan 15 at 15:51

answered Jan 15 at 14:14

dbush

98.4k13104138

It is perhaps relevant to include that the scope of identifier i begins at the end of its declarator, of which the initializer is not part. Thus i is in scope in its own initializer, even though it is not useful to initialize it with itself.

– John Bollinger
Jan 15 at 14:26

Also, there's a bit of a wiggly issue around C11 6.3.2.1/2, though I don't think that makes your analysis incorrect.

– John Bollinger
Jan 15 at 14:32

Can you elaborate this, better with reference to the standard?

– Hongxu Chen
Jan 15 at 14:36

@JohnBollinger This answer is essentially correct. The complete story including the 6.3.2.1 special case can be found here: (Why) is using an uninitialized variable undefined behavior?

– Lundin
Jan 15 at 15:43

1

@JohnBollinger Added further detail on whether i had its address taken.

– dbush
Jan 15 at 15:52

|
show 6 more comments

This is a warning, it's not related to the standard.

Warnings are heuristic with "optimistic" approach. The warning is issued only when the compiler is sure that it's going to be a problem. In cases like this you have better luck with clang or newest versions of gcc as stated in comments (see another related question of mine: why am I not getting an "used uninitialized" warning from gcc in this trivial example?).

anyway, in the first case:

int i = i;

does nothing, since i==i already. It is possible that the assignment is completely optimized out as it's useless. With compilers which don't "see" self-initialization as a problem you can do this without a warning:

int i = i;

printf("%dn",i);

Whereas this triggers a warning all right:

int i;

printf("%dn",i);

Still, it's bad enough not to be warned about this, since from now on i is seen as initialized.

In the second case:

int i = i + 1;

A computation between an uninitialized value and 1 must be performed. Undefined behaviour happens there.

edited Jan 15 at 14:34

answered Jan 15 at 14:09

Jean-François Fabre

104k955112

1

Good answer; however, I am not sure about the "warnings issued, when the compiler is sure that there is going to be a problem". There are many warnings, where this isn't the case, this is highly dependent on the warning types enabled

– Ctx
Jan 15 at 14:12

1

The risk with int i = i + 1 is that UB is UB, period. Also, signed overflow. Also, much scratching of heads when another coder has to make sense of that code at some later point.

– DevSolar
Jan 15 at 14:13

true! I forgot the sign. Edited out to make it simple

– Jean-François Fabre
Jan 15 at 14:14

As @Ctx says. For example, I often find myself building third-party code that causes tons of warnings about use of possibly uninitialized variables. Control-flow analysis in those cases normally shows that the programmer included appropriate logic to ensure that the variable is assigned a value before its value is used. But the compiler is explicitly unsure whether there is a problem.

– John Bollinger
Jan 15 at 14:15

-Wparentheses would be another example.

– Osiris
Jan 15 at 14:23

|
show 2 more comments

I believe you are okay with getting the warning in case of

int i = i + 1;

as expected, however, you expect the warning to be displayed even in case of

int i = i;

also.

Why is this even allowed by compilers?

There is nothing inherently wrong with the statement. See the related discussions:

Why does the compiler allow initializing a variable with itself?

Why is initialization of a new variable by itself valid?

for more insight.

What does the C/C++ standards say about this? Specifically, what's the behavior of this? UB or implementation dependent?

This is undefined behavior, as the type int can have trap representation and you never have taken the address of the variable in discussion. So, technically, you'll face UB as soon as you try to use the (indeterminate) value stored in variable i.

You should turn on your compiler warnings. In gcc,

compile with -Winit-self to get a warning. in C.

For C++, -Winit-self is enabled with -Wall already.

edited Jan 15 at 15:25

answered Jan 15 at 14:09

Sourav Ghosh

110k14130188

no dice with -Winit-self either here, using gcc 7.3.1

– Jean-François Fabre
Jan 15 at 14:10

@Jean-FrançoisFabre I get that

– Sourav Ghosh
Jan 15 at 14:17

you have a new version of gcc. Mine is older. When you say "probable source of undefined behavior (if the value of the variable is used later on)" it's the same as using it uninitialized.

– Jean-François Fabre
Jan 15 at 14:18

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',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

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

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54200465%2fwhats-the-behavior-of-an-uninitialized-variable-used-as-its-own-initializer%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

3 Answers
3

active

oldest

votes

3 Answers
3

active

oldest

votes

Because i is uninitialized when use to initialize itself, it has an indeterminate value at that time. An indeterminate value can be either an unspecified value or a trap representation.

If your implementation supports padding bits in integer types and if the indeterminate value in question happens to be a trap representation, then using it results in undefined behavior.

If your implementation does not have padding in integers, then the value is simply unspecified and there is no undefined behavior.

EDIT:

To elaborate further, the behavior can still be undefined if i never has its address taken at some point. This is detailed in section 6.3.2.1p2 of the C11 standard:

If the lvalue designates an object of automatic storage
duration that could have been declared with the register storage
class (never had its address taken), and that object is uninitialized
(not declared with an initializer and no assignment to it
has been performed prior to use), the behavior is undefined.

So if you never take the address of i, then you have undefined behavior. Otherwise, the statements above apply.

edited Jan 15 at 15:51

answered Jan 15 at 14:14

dbush

98.4k13104138

It is perhaps relevant to include that the scope of identifier i begins at the end of its declarator, of which the initializer is not part. Thus i is in scope in its own initializer, even though it is not useful to initialize it with itself.

– John Bollinger
Jan 15 at 14:26

Also, there's a bit of a wiggly issue around C11 6.3.2.1/2, though I don't think that makes your analysis incorrect.

– John Bollinger
Jan 15 at 14:32

Can you elaborate this, better with reference to the standard?

– Hongxu Chen
Jan 15 at 14:36

@JohnBollinger This answer is essentially correct. The complete story including the 6.3.2.1 special case can be found here: (Why) is using an uninitialized variable undefined behavior?

– Lundin
Jan 15 at 15:43

1

@JohnBollinger Added further detail on whether i had its address taken.

– dbush
Jan 15 at 15:52

|
show 6 more comments

Because i is uninitialized when use to initialize itself, it has an indeterminate value at that time. An indeterminate value can be either an unspecified value or a trap representation.

If your implementation supports padding bits in integer types and if the indeterminate value in question happens to be a trap representation, then using it results in undefined behavior.

If your implementation does not have padding in integers, then the value is simply unspecified and there is no undefined behavior.

EDIT:

To elaborate further, the behavior can still be undefined if i never has its address taken at some point. This is detailed in section 6.3.2.1p2 of the C11 standard:

If the lvalue designates an object of automatic storage
duration that could have been declared with the register storage
class (never had its address taken), and that object is uninitialized
(not declared with an initializer and no assignment to it
has been performed prior to use), the behavior is undefined.

So if you never take the address of i, then you have undefined behavior. Otherwise, the statements above apply.

edited Jan 15 at 15:51

answered Jan 15 at 14:14

dbush

98.4k13104138

It is perhaps relevant to include that the scope of identifier i begins at the end of its declarator, of which the initializer is not part. Thus i is in scope in its own initializer, even though it is not useful to initialize it with itself.

– John Bollinger
Jan 15 at 14:26

Also, there's a bit of a wiggly issue around C11 6.3.2.1/2, though I don't think that makes your analysis incorrect.

– John Bollinger
Jan 15 at 14:32

Can you elaborate this, better with reference to the standard?

– Hongxu Chen
Jan 15 at 14:36

@JohnBollinger This answer is essentially correct. The complete story including the 6.3.2.1 special case can be found here: (Why) is using an uninitialized variable undefined behavior?

– Lundin
Jan 15 at 15:43

1

@JohnBollinger Added further detail on whether i had its address taken.

– dbush
Jan 15 at 15:52

|
show 6 more comments

Because i is uninitialized when use to initialize itself, it has an indeterminate value at that time. An indeterminate value can be either an unspecified value or a trap representation.

If your implementation supports padding bits in integer types and if the indeterminate value in question happens to be a trap representation, then using it results in undefined behavior.

If your implementation does not have padding in integers, then the value is simply unspecified and there is no undefined behavior.

EDIT:

To elaborate further, the behavior can still be undefined if i never has its address taken at some point. This is detailed in section 6.3.2.1p2 of the C11 standard:

If the lvalue designates an object of automatic storage
duration that could have been declared with the register storage
class (never had its address taken), and that object is uninitialized
(not declared with an initializer and no assignment to it
has been performed prior to use), the behavior is undefined.

So if you never take the address of i, then you have undefined behavior. Otherwise, the statements above apply.

edited Jan 15 at 15:51

answered Jan 15 at 14:14

dbush

98.4k13104138

Because i is uninitialized when use to initialize itself, it has an indeterminate value at that time. An indeterminate value can be either an unspecified value or a trap representation.

If your implementation supports padding bits in integer types and if the indeterminate value in question happens to be a trap representation, then using it results in undefined behavior.

If your implementation does not have padding in integers, then the value is simply unspecified and there is no undefined behavior.

EDIT:

To elaborate further, the behavior can still be undefined if i never has its address taken at some point. This is detailed in section 6.3.2.1p2 of the C11 standard:

If the lvalue designates an object of automatic storage
duration that could have been declared with the register storage
class (never had its address taken), and that object is uninitialized
(not declared with an initializer and no assignment to it
has been performed prior to use), the behavior is undefined.

So if you never take the address of i, then you have undefined behavior. Otherwise, the statements above apply.

edited Jan 15 at 15:51

answered Jan 15 at 14:14

dbush

98.4k13104138

edited Jan 15 at 15:51

answered Jan 15 at 14:14

dbush

98.4k13104138

answered Jan 15 at 14:14

dbush

98.4k13104138

answered Jan 15 at 14:14

dbush

98.4k13104138

It is perhaps relevant to include that the scope of identifier i begins at the end of its declarator, of which the initializer is not part. Thus i is in scope in its own initializer, even though it is not useful to initialize it with itself.

– John Bollinger
Jan 15 at 14:26

Also, there's a bit of a wiggly issue around C11 6.3.2.1/2, though I don't think that makes your analysis incorrect.

– John Bollinger
Jan 15 at 14:32

Can you elaborate this, better with reference to the standard?

– Hongxu Chen
Jan 15 at 14:36

@JohnBollinger This answer is essentially correct. The complete story including the 6.3.2.1 special case can be found here: (Why) is using an uninitialized variable undefined behavior?

– Lundin
Jan 15 at 15:43

1

@JohnBollinger Added further detail on whether i had its address taken.

– dbush
Jan 15 at 15:52

|
show 6 more comments

It is perhaps relevant to include that the scope of identifier i begins at the end of its declarator, of which the initializer is not part. Thus i is in scope in its own initializer, even though it is not useful to initialize it with itself.

– John Bollinger
Jan 15 at 14:26

Also, there's a bit of a wiggly issue around C11 6.3.2.1/2, though I don't think that makes your analysis incorrect.

– John Bollinger
Jan 15 at 14:32

Can you elaborate this, better with reference to the standard?

– Hongxu Chen
Jan 15 at 14:36

@JohnBollinger This answer is essentially correct. The complete story including the 6.3.2.1 special case can be found here: (Why) is using an uninitialized variable undefined behavior?

– Lundin
Jan 15 at 15:43

1

@JohnBollinger Added further detail on whether i had its address taken.

– dbush
Jan 15 at 15:52

It is perhaps relevant to include that the scope of identifier i begins at the end of its declarator, of which the initializer is not part. Thus i is in scope in its own initializer, even though it is not useful to initialize it with itself.

– John Bollinger
Jan 15 at 14:26

Also, there's a bit of a wiggly issue around C11 6.3.2.1/2, though I don't think that makes your analysis incorrect.

– John Bollinger
Jan 15 at 14:32

Can you elaborate this, better with reference to the standard?

– Hongxu Chen
Jan 15 at 14:36

@JohnBollinger This answer is essentially correct. The complete story including the 6.3.2.1 special case can be found here: (Why) is using an uninitialized variable undefined behavior?

– Lundin
Jan 15 at 15:43

@JohnBollinger Added further detail on whether i had its address taken.

– dbush
Jan 15 at 15:52

|
show 6 more comments

This is a warning, it's not related to the standard.

anyway, in the first case:

int i = i;

int i = i;

printf("%dn",i);

Whereas this triggers a warning all right:

int i;

printf("%dn",i);

Still, it's bad enough not to be warned about this, since from now on i is seen as initialized.

In the second case:

int i = i + 1;

A computation between an uninitialized value and 1 must be performed. Undefined behaviour happens there.

edited Jan 15 at 14:34

answered Jan 15 at 14:09

Jean-François Fabre

104k955112

1

Good answer; however, I am not sure about the "warnings issued, when the compiler is sure that there is going to be a problem". There are many warnings, where this isn't the case, this is highly dependent on the warning types enabled

– Ctx
Jan 15 at 14:12

1

The risk with int i = i + 1 is that UB is UB, period. Also, signed overflow. Also, much scratching of heads when another coder has to make sense of that code at some later point.

– DevSolar
Jan 15 at 14:13

true! I forgot the sign. Edited out to make it simple

– Jean-François Fabre
Jan 15 at 14:14

As @Ctx says. For example, I often find myself building third-party code that causes tons of warnings about use of possibly uninitialized variables. Control-flow analysis in those cases normally shows that the programmer included appropriate logic to ensure that the variable is assigned a value before its value is used. But the compiler is explicitly unsure whether there is a problem.

– John Bollinger
Jan 15 at 14:15

-Wparentheses would be another example.

– Osiris
Jan 15 at 14:23

|
show 2 more comments

This is a warning, it's not related to the standard.

anyway, in the first case:

int i = i;

int i = i;

printf("%dn",i);

Whereas this triggers a warning all right:

int i;

printf("%dn",i);

Still, it's bad enough not to be warned about this, since from now on i is seen as initialized.

In the second case:

int i = i + 1;

A computation between an uninitialized value and 1 must be performed. Undefined behaviour happens there.

edited Jan 15 at 14:34

answered Jan 15 at 14:09

Jean-François Fabre

104k955112

1

Good answer; however, I am not sure about the "warnings issued, when the compiler is sure that there is going to be a problem". There are many warnings, where this isn't the case, this is highly dependent on the warning types enabled

– Ctx
Jan 15 at 14:12

1

The risk with int i = i + 1 is that UB is UB, period. Also, signed overflow. Also, much scratching of heads when another coder has to make sense of that code at some later point.

– DevSolar
Jan 15 at 14:13

true! I forgot the sign. Edited out to make it simple

– Jean-François Fabre
Jan 15 at 14:14

As @Ctx says. For example, I often find myself building third-party code that causes tons of warnings about use of possibly uninitialized variables. Control-flow analysis in those cases normally shows that the programmer included appropriate logic to ensure that the variable is assigned a value before its value is used. But the compiler is explicitly unsure whether there is a problem.

– John Bollinger
Jan 15 at 14:15

-Wparentheses would be another example.

– Osiris
Jan 15 at 14:23

|
show 2 more comments

This is a warning, it's not related to the standard.

anyway, in the first case:

int i = i;

int i = i;

printf("%dn",i);

Whereas this triggers a warning all right:

int i;

printf("%dn",i);

Still, it's bad enough not to be warned about this, since from now on i is seen as initialized.

In the second case:

int i = i + 1;

A computation between an uninitialized value and 1 must be performed. Undefined behaviour happens there.

edited Jan 15 at 14:34

answered Jan 15 at 14:09

Jean-François Fabre

104k955112

This is a warning, it's not related to the standard.

anyway, in the first case:

int i = i;

int i = i;

printf("%dn",i);

Whereas this triggers a warning all right:

int i;

printf("%dn",i);

Still, it's bad enough not to be warned about this, since from now on i is seen as initialized.

In the second case:

int i = i + 1;

A computation between an uninitialized value and 1 must be performed. Undefined behaviour happens there.

edited Jan 15 at 14:34

answered Jan 15 at 14:09

Jean-François Fabre

104k955112

edited Jan 15 at 14:34

answered Jan 15 at 14:09

Jean-François Fabre

104k955112

answered Jan 15 at 14:09

Jean-François Fabre

104k955112

answered Jan 15 at 14:09

Jean-François Fabre

104k955112

1

Good answer; however, I am not sure about the "warnings issued, when the compiler is sure that there is going to be a problem". There are many warnings, where this isn't the case, this is highly dependent on the warning types enabled

– Ctx
Jan 15 at 14:12

1

The risk with int i = i + 1 is that UB is UB, period. Also, signed overflow. Also, much scratching of heads when another coder has to make sense of that code at some later point.

– DevSolar
Jan 15 at 14:13

true! I forgot the sign. Edited out to make it simple

– Jean-François Fabre
Jan 15 at 14:14

As @Ctx says. For example, I often find myself building third-party code that causes tons of warnings about use of possibly uninitialized variables. Control-flow analysis in those cases normally shows that the programmer included appropriate logic to ensure that the variable is assigned a value before its value is used. But the compiler is explicitly unsure whether there is a problem.

– John Bollinger
Jan 15 at 14:15

-Wparentheses would be another example.

– Osiris
Jan 15 at 14:23

|
show 2 more comments

1

Good answer; however, I am not sure about the "warnings issued, when the compiler is sure that there is going to be a problem". There are many warnings, where this isn't the case, this is highly dependent on the warning types enabled

– Ctx
Jan 15 at 14:12

1

The risk with int i = i + 1 is that UB is UB, period. Also, signed overflow. Also, much scratching of heads when another coder has to make sense of that code at some later point.

– DevSolar
Jan 15 at 14:13

true! I forgot the sign. Edited out to make it simple

– Jean-François Fabre
Jan 15 at 14:14

As @Ctx says. For example, I often find myself building third-party code that causes tons of warnings about use of possibly uninitialized variables. Control-flow analysis in those cases normally shows that the programmer included appropriate logic to ensure that the variable is assigned a value before its value is used. But the compiler is explicitly unsure whether there is a problem.

– John Bollinger
Jan 15 at 14:15

-Wparentheses would be another example.

– Osiris
Jan 15 at 14:23

Good answer; however, I am not sure about the "warnings issued, when the compiler is sure that there is going to be a problem". There are many warnings, where this isn't the case, this is highly dependent on the warning types enabled

– Ctx
Jan 15 at 14:12

The risk with int i = i + 1 is that UB is UB, period. Also, signed overflow. Also, much scratching of heads when another coder has to make sense of that code at some later point.

– DevSolar
Jan 15 at 14:13

true! I forgot the sign. Edited out to make it simple

– Jean-François Fabre
Jan 15 at 14:14

As @Ctx says. For example, I often find myself building third-party code that causes tons of warnings about use of possibly uninitialized variables. Control-flow analysis in those cases normally shows that the programmer included appropriate logic to ensure that the variable is assigned a value before its value is used. But the compiler is explicitly unsure whether there is a problem.

– John Bollinger
Jan 15 at 14:15

-Wparentheses would be another example.

– Osiris
Jan 15 at 14:23

|
show 2 more comments

I believe you are okay with getting the warning in case of

int i = i + 1;

as expected, however, you expect the warning to be displayed even in case of

int i = i;

also.

Why is this even allowed by compilers?

There is nothing inherently wrong with the statement. See the related discussions:

Why does the compiler allow initializing a variable with itself?

Why is initialization of a new variable by itself valid?

for more insight.

What does the C/C++ standards say about this? Specifically, what's the behavior of this? UB or implementation dependent?

You should turn on your compiler warnings. In gcc,

compile with -Winit-self to get a warning. in C.

For C++, -Winit-self is enabled with -Wall already.

edited Jan 15 at 15:25

answered Jan 15 at 14:09

Sourav Ghosh

110k14130188

no dice with -Winit-self either here, using gcc 7.3.1

– Jean-François Fabre
Jan 15 at 14:10

@Jean-FrançoisFabre I get that

– Sourav Ghosh
Jan 15 at 14:17

you have a new version of gcc. Mine is older. When you say "probable source of undefined behavior (if the value of the variable is used later on)" it's the same as using it uninitialized.

– Jean-François Fabre
Jan 15 at 14:18

add a comment |

I believe you are okay with getting the warning in case of

int i = i + 1;

as expected, however, you expect the warning to be displayed even in case of

int i = i;

also.

Why is this even allowed by compilers?

There is nothing inherently wrong with the statement. See the related discussions:

Why does the compiler allow initializing a variable with itself?

Why is initialization of a new variable by itself valid?

for more insight.

What does the C/C++ standards say about this? Specifically, what's the behavior of this? UB or implementation dependent?

You should turn on your compiler warnings. In gcc,

compile with -Winit-self to get a warning. in C.

For C++, -Winit-self is enabled with -Wall already.

edited Jan 15 at 15:25

answered Jan 15 at 14:09

Sourav Ghosh

110k14130188

no dice with -Winit-self either here, using gcc 7.3.1

– Jean-François Fabre
Jan 15 at 14:10

@Jean-FrançoisFabre I get that

– Sourav Ghosh
Jan 15 at 14:17

you have a new version of gcc. Mine is older. When you say "probable source of undefined behavior (if the value of the variable is used later on)" it's the same as using it uninitialized.

– Jean-François Fabre
Jan 15 at 14:18

add a comment |

I believe you are okay with getting the warning in case of

int i = i + 1;

as expected, however, you expect the warning to be displayed even in case of

int i = i;

also.

Why is this even allowed by compilers?

There is nothing inherently wrong with the statement. See the related discussions:

Why does the compiler allow initializing a variable with itself?

Why is initialization of a new variable by itself valid?

for more insight.

What does the C/C++ standards say about this? Specifically, what's the behavior of this? UB or implementation dependent?

You should turn on your compiler warnings. In gcc,

compile with -Winit-self to get a warning. in C.

For C++, -Winit-self is enabled with -Wall already.

edited Jan 15 at 15:25

answered Jan 15 at 14:09

Sourav Ghosh

110k14130188

I believe you are okay with getting the warning in case of

int i = i + 1;

as expected, however, you expect the warning to be displayed even in case of

int i = i;

also.

Why is this even allowed by compilers?

There is nothing inherently wrong with the statement. See the related discussions:

Why does the compiler allow initializing a variable with itself?

Why is initialization of a new variable by itself valid?

for more insight.

What does the C/C++ standards say about this? Specifically, what's the behavior of this? UB or implementation dependent?

You should turn on your compiler warnings. In gcc,

compile with -Winit-self to get a warning. in C.

For C++, -Winit-self is enabled with -Wall already.

edited Jan 15 at 15:25

answered Jan 15 at 14:09

Sourav Ghosh

110k14130188

edited Jan 15 at 15:25

answered Jan 15 at 14:09

Sourav Ghosh

110k14130188

answered Jan 15 at 14:09

Sourav Ghosh

110k14130188

answered Jan 15 at 14:09

Sourav Ghosh

110k14130188

no dice with -Winit-self either here, using gcc 7.3.1

– Jean-François Fabre
Jan 15 at 14:10

@Jean-FrançoisFabre I get that

– Sourav Ghosh
Jan 15 at 14:17

you have a new version of gcc. Mine is older. When you say "probable source of undefined behavior (if the value of the variable is used later on)" it's the same as using it uninitialized.

– Jean-François Fabre
Jan 15 at 14:18

add a comment |

no dice with -Winit-self either here, using gcc 7.3.1

– Jean-François Fabre
Jan 15 at 14:10

@Jean-FrançoisFabre I get that

– Sourav Ghosh
Jan 15 at 14:17

you have a new version of gcc. Mine is older. When you say "probable source of undefined behavior (if the value of the variable is used later on)" it's the same as using it uninitialized.

– Jean-François Fabre
Jan 15 at 14:18

no dice with -Winit-self either here, using gcc 7.3.1

– Jean-François Fabre
Jan 15 at 14:10

@Jean-FrançoisFabre I get that

– Sourav Ghosh
Jan 15 at 14:17

you have a new version of gcc. Mine is older. When you say "probable source of undefined behavior (if the value of the variable is used later on)" it's the same as using it uninitialized.

– Jean-François Fabre
Jan 15 at 14:18

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

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

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

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

Post as a guest

Name

Required, but never shown

Sign up or log in

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

Post as a guest

Name

Required, but never shown

Sign up or log in

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

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu