Related articles |
---|
Undefined behaviour, was: for or against equality martin@gkc.org.uk (Martin Ward) (2022-01-07) |
Re: Undefined behaviour, was: for or against equality david.brown@hesbynett.no (David Brown) (2022-01-07) |
Re: Undefined behaviour, was: for or against equality spibou@gmail.com (Spiros Bousbouras) (2022-01-08) |
Re: Undefined behaviour, was: for or against equality anton@mips.complang.tuwien.ac.at (2022-01-08) |
Re: Undefined behaviour, was: for or against equality david.brown@hesbynett.no (David Brown) (2022-01-09) |
Re: Undefined behaviour, was: for or against equality 480-992-1380@kylheku.com (Kaz Kylheku) (2022-01-11) |
Re: Undefined behaviour, was: for or against equality gneuner2@comcast.net (George Neuner) (2022-01-11) |
From: | Spiros Bousbouras <spibou@gmail.com> |
Newsgroups: | comp.compilers |
Date: | Sat, 8 Jan 2022 03:41:55 -0000 (UTC) |
Organization: | Aioe.org NNTP Server |
References: | <17d70d74-1cf1-cc41-6b38-c0b307aeb35a@gkc.org.uk> 22-01-016 22-01-018 22-01-028 |
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-Organisation: | Weyland-Yutani |
On Fri, 7 Jan 2022 14:02:50 +0000
Martin Ward <martin@gkc.org.uk> 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 .
Return to the
comp.compilers page.
Search the
comp.compilers archives again.