Path: csiph.com!goblin3!goblin.stu.neva.ru!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Kaz Kylheku <847-115-0292@kylheku.com> Newsgroups: comp.compilers Subject: Re: language design and Optimization techniques Date: Fri, 26 Apr 2019 21:06:46 +0000 (UTC) Organization: Aioe.org NNTP Server Lines: 68 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-04-029@comp.compilers> References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> <910eaf6f-f9ae-9c02-5052-f06474024d96@hesbynett.no> <19-04-027@comp.compilers> Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="87345"; mail-complaints-to="abuse@iecc.com" Keywords: design, optimize Posted-Date: 27 Apr 2019 10:15:51 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:2213 On 2019-04-26, Martin Ward wrote: > On 25/04/19 20:58, David Brown wrote: >> It is a serious mistake to mix up "defined behaviour" and "correct >> behaviour". Only defined behaviour can be correct, but you can't fix >> incorrect code by making it defined behaviour. > > "Defined behaviour" *can* be "correct behaviour" > "undefined behaviour" can *never* be correct and therefore > must be avoided at all costs. That is only right if we are talking about *absolutely* undefined behavior. The term "undefined behavior" in a programming language standrad isn't absolute. It just refers to a way of using a language for which the standard imposes no requirements. Some undefined behaviors are used for providing documented extensions. In C, all platforms-specific functions are essentially such an extension. Consider that if we write this program: int main(void) { extern int write(double); return write(3.14); } We have not defined the external symbol "write" anywhere, and so this will fail to link on many platforms. That failure is allowed because of "undefined behavior". Now if we compile this on a POSIX system, it almost certainly will link; we get an executable which calls the POSIX write function with invalid, incompatible arguments. The consequences of this are also consistent with "undefined behavior". There could be a platform where there is an int write(double), where the program is just fine! Also allowed by undefined behavior. The unescapable interpretation is that the use of platform libraries constitutes the use of documented extensions that supplant undefined behavior. A program that uses a platform specific function, interpreted in a pure standard context, can have any behavior whatsoever: failing to link, crashing, or producing the expectd behavior. None of those behaviors is specifically required, and the choice of behavior is not required to be documented. > You dismiss cases of security holes due to undefined behaviour > as "just program bugs, because programmers didn't do the right thing". > The C ANSI standard is over 500 pages long and includes 199 > different cases of undefined behaviour. A quick quiz: > without referencing the standard, how many of the 199 cases > of undefined behaviour can you list off the top of your head? > Remember: a *good* programmer (one that you would describe > as an engineer who knows what they are doing) must avoid > all 199 cases of undefined behaviour in every line of code > that they write. Not all cases are potentially relevant to every line of code. For instance, only one line of code in the program can commit the error of "void main". That line "takes one for the team", so the remaining lines face at most 198 threats. :)