Date: Wed, 27 May 2020 08:44:45 +0000
I come from an embedded systems perspective and this loops UB thing means most embedded projects have UB. I would also prefer this not part of <cstdlib>, I think that's quite a heavy handed way to deal with this UB.
Requiring <cstdlib> for something as basic as a while loop that isn't removed, is unintuitive.
I agree with your suggestion regarding for(;[true];) and while(true). To someone reading code that has a while(true) it is obvious what the programmer intends.
Some related:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1509.pdf
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528.htm
-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of std-proposals-request_at_[hidden]
Sent: 27 May 2020 3:00 AM
To: std-proposals_at_[hidden]
Subject: Std-Proposals Digest, Vol 14, Issue 35
Send Std-Proposals mailing list submissions to
std-proposals_at_[hidden]
To subscribe or unsubscribe via the World Wide Web, visit
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=02%7C01%7C%7C27a4a5de403f4a259be208d80195db66%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637261090425240452&sdata=dH%2FCNpM9OY3fdufFx0OrmH9N8rlVXWMkiDyYMdvPeg0%3D&reserved=0
or, via email, send a message with subject or body 'help' to
std-proposals-request_at_[hidden]
You can reach the person managing the list at
std-proposals-owner_at_[hidden]
When replying, please edit your Subject line so it is more specific than "Re: Contents of Std-Proposals digest..."
Today's Topics:
1. Re: Remove infinite loop UB (Rand McRanderson)
----------------------------------------------------------------------
Message: 1
Date: Tue, 26 May 2020 09:02:38 -0400
From: Rand McRanderson <therandshow_at_[hidden]>
To: std-proposals_at_[hidden]
Subject: Re: [std-proposals] Remove infinite loop UB
Message-ID:
<CAAFmJiFYmv+f6TsggKg-P2WvksGjKnfQZJf0eq3oAhpoE0-qsg_at_[hidden]>
Content-Type: text/plain; charset="UTF-8"
Hi,
First time posting here. Regarding infinite loops, the situation we have now is most embedded programmers use some form of infinite loop tailored to their specific compiler and board. This means whenever they change compilers or boards there is a chance things could break.
So giving some way for a programmer to signal, yes this is a wait-for-interrupts loop according to the dictates of the platform would be very helpful.
On the other hand, I can see where simply making infinite loops not undefined behavior could cause problems, specifically in cases like loop elimination for inline functions, it would become ambiguous if a no-op loop for a particular function context is actually no-op or intended to do a wait of some sort unless the compiler can be sure it terminates. This could be mitigated by requiring infinite loops be explicitly infinite, ie while(1) or for(;;)
The other danger is that by making code that previously was broken (ie, has infinite loops, but those currently are being eliminated, maybe the loops were originally added for a specific platform or had specific annotations to make them work that were not portable), it could change the behavior of existing code in a way that might be surprising to a legacy project that is recompiling code where they had been ignoring these old previously harmless infinite loops. Not sure if that is a real danger though, might be a hypothetical situation that would not occur in real life.
Overall, I really like the proposal of p1494. I would prefer probably that it not be in cstdlib, just because a lot of embedded programmers might not have that header available, but I can understand that there might not be any better place to put it.
------------------------------
Subject: Digest Footer
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=02%7C01%7C%7C27a4a5de403f4a259be208d80195db66%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637261090425240452&sdata=dH%2FCNpM9OY3fdufFx0OrmH9N8rlVXWMkiDyYMdvPeg0%3D&reserved=0
------------------------------
End of Std-Proposals Digest, Vol 14, Issue 35
*********************************************
Requiring <cstdlib> for something as basic as a while loop that isn't removed, is unintuitive.
I agree with your suggestion regarding for(;[true];) and while(true). To someone reading code that has a while(true) it is obvious what the programmer intends.
Some related:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1509.pdf
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528.htm
-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of std-proposals-request_at_[hidden]
Sent: 27 May 2020 3:00 AM
To: std-proposals_at_[hidden]
Subject: Std-Proposals Digest, Vol 14, Issue 35
Send Std-Proposals mailing list submissions to
std-proposals_at_[hidden]
To subscribe or unsubscribe via the World Wide Web, visit
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=02%7C01%7C%7C27a4a5de403f4a259be208d80195db66%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637261090425240452&sdata=dH%2FCNpM9OY3fdufFx0OrmH9N8rlVXWMkiDyYMdvPeg0%3D&reserved=0
or, via email, send a message with subject or body 'help' to
std-proposals-request_at_[hidden]
You can reach the person managing the list at
std-proposals-owner_at_[hidden]
When replying, please edit your Subject line so it is more specific than "Re: Contents of Std-Proposals digest..."
Today's Topics:
1. Re: Remove infinite loop UB (Rand McRanderson)
----------------------------------------------------------------------
Message: 1
Date: Tue, 26 May 2020 09:02:38 -0400
From: Rand McRanderson <therandshow_at_[hidden]>
To: std-proposals_at_[hidden]
Subject: Re: [std-proposals] Remove infinite loop UB
Message-ID:
<CAAFmJiFYmv+f6TsggKg-P2WvksGjKnfQZJf0eq3oAhpoE0-qsg_at_[hidden]>
Content-Type: text/plain; charset="UTF-8"
Hi,
First time posting here. Regarding infinite loops, the situation we have now is most embedded programmers use some form of infinite loop tailored to their specific compiler and board. This means whenever they change compilers or boards there is a chance things could break.
So giving some way for a programmer to signal, yes this is a wait-for-interrupts loop according to the dictates of the platform would be very helpful.
On the other hand, I can see where simply making infinite loops not undefined behavior could cause problems, specifically in cases like loop elimination for inline functions, it would become ambiguous if a no-op loop for a particular function context is actually no-op or intended to do a wait of some sort unless the compiler can be sure it terminates. This could be mitigated by requiring infinite loops be explicitly infinite, ie while(1) or for(;;)
The other danger is that by making code that previously was broken (ie, has infinite loops, but those currently are being eliminated, maybe the loops were originally added for a specific platform or had specific annotations to make them work that were not portable), it could change the behavior of existing code in a way that might be surprising to a legacy project that is recompiling code where they had been ignoring these old previously harmless infinite loops. Not sure if that is a real danger though, might be a hypothetical situation that would not occur in real life.
Overall, I really like the proposal of p1494. I would prefer probably that it not be in cstdlib, just because a lot of embedded programmers might not have that header available, but I can understand that there might not be any better place to put it.
------------------------------
Subject: Digest Footer
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=02%7C01%7C%7C27a4a5de403f4a259be208d80195db66%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637261090425240452&sdata=dH%2FCNpM9OY3fdufFx0OrmH9N8rlVXWMkiDyYMdvPeg0%3D&reserved=0
------------------------------
End of Std-Proposals Digest, Vol 14, Issue 35
*********************************************
Received on 2020-05-27 03:47:52