Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Spiros Bousbouras Newsgroups: comp.compilers Subject: Re: Undefined behaviour, was: for or against equality Date: Sat, 8 Jan 2022 03:41:55 -0000 (UTC) Organization: Aioe.org NNTP Server Lines: 47 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <22-01-031@comp.compilers> References: <17d70d74-1cf1-cc41-6b38-c0b307aeb35a@gkc.org.uk> <22-01-016@comp.compilers> <22-01-018@comp.compilers> <22-01-028@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="54542"; mail-complaints-to="abuse@iecc.com" Keywords: standards Posted-Date: 07 Jan 2022 23:12:52 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com X-Organisation: Weyland-Yutani Xref: csiph.com comp.compilers:2807 On Fri, 7 Jan 2022 14:02:50 +0000 Martin Ward wrote: > On 06/01/2022 08:11, David Brown wrote: > > The trick is to memorize the/defined/ behaviours, and stick to them. > > Isn't the set of defined behaviours bigger than the set > of undefined behaviours? That depends on how you define those sets. For example, any finite string is a potential C source code and, of strings of length N (for any value of N), only a very small percentage have defined behaviour. But regardless, you need to know at least some defined behaviours to be able to programme at all and, as long as you stick to those, you are not using any undefined behaviours. > How do you know what is defined > if you don't know what is undefined? As David has already said, you know by reading the definitions. And this is the only way to know. Trying to guess what you're getting at, perhaps you are thinking of someone who learns some C, then makes some unwarranted assumptions from what they have learned and then has those assumptions scaled back by coming across explicit mentions of "undefined behaviour" in the C standard. Perhaps some people do behave this way. For example someone who already knows assembly and begins to learn C may assume that all address manipulations which would be legal in assembly are also legal using C pointers. The correct remedy is not to make unwarranted assumptions to begin with, whether one learns C or any other programming language. There is an infinite number of unwarranted assumptions one can make and the C standard can only caution against a finite number of them. > For example, a = b + c is precisely defined in C and C++ for > floating point variables, but the result can be "undefined behaviour" > for ordinary 32 bit signed integer values. > > If you want to stick to defined behaviours then you need > to add extra code. For example, CERT recommends: > > if (((si_b > 0) && (si_a > (INT_MAX - si_b))) || > ((si_b < 0) && (si_a < (INT_MIN - si_b)))) { > /* Handle error */ > } else { > sum = si_a + si_b; > } Whether you need to add code as the above will depend on what you already know about the types and values of si_a and si_b .