Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Date: Wed, 12 Aug 2020 16:18:14 -0700 Organization: None to speak of Lines: 36 Message-ID: <87364r313d.fsf@nosuchdomain.example.com> References: <877du33by4.fsf@nosuchdomain.example.com> <20200813011941.db77ae6904762d755c696eda@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="8bedd1e3a6b64f4bfed27905c7e8e80c"; logging-data="24168"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18XPT1yCUHzJhFLOLK3HtmA" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:ikkQMhdPXK1oPnR/5seZogWD+Yo= sha1:jOxSuQiuKQ1+yxH8QwGCUxY1ShI= Xref: csiph.com comp.lang.c:153582 Anton Shepelev writes: > Keith Thompson: > >> C isn't nearly as lax as he implies it is. > > I agree with you and Elijah. C would be making a much > better impression but for slipshod programmers and compiler > writers that cater for them. It should be good tone and > taken for granted that compilers should not accept programs > with errors and underfined behavior. Instances of undefined > behavior should be considered individually and compilers > instructed to accept them on a case-by-case basis. In many (most?) cases, constructs that have undefined behavior are defined that way because they're errors that are impossible to detect in all cases. Consider signed integer overflow, for example. C only requires a diagnostic (which can be non-fatal) for a violation of a syntax rule or constraint. My personal preference would have been to require all such errors to be fatal. Compilers could always have non-conforming options that tell them to allow bad code, and it compilers could still be non-conforming by default. But the current situation isn't too much different; it's mostly just a matter of picking the right options. Most compilers *can* be invoked in a mode that rejects all syntax errors and constraint violations with fatal errors. The code in the article (that initialized a pointer object with a value of a different pointer type) would almost certainly be rejected on any real-world project. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */