Path: csiph.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Hans-Peter Diettrich Newsgroups: comp.compilers Subject: Re: diagnosing C errors, was Alternative C compilers on x86_64 Linux? Date: Sat, 10 Sep 2016 00:38:31 +0200 Organization: Compilers Central Lines: 59 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <16-09-024@comp.compilers> References: <16-09-001@comp.compilers> <16-09-002@comp.compilers> <16-09-008@comp.compilers> <16-09-019@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="97539"; mail-complaints-to="abuse@iecc.com" Keywords: C, syntax Posted-Date: 12 Sep 2016 14:59:24 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:1763 BartC schrieb: > For example, take a pointer to an array of ints, P. You'd normally > access an int by dereferencing P then applying the index: (*P)[i]. > > But if, by mistake, you index first then dereference: *(P[i]), then this > still compiles. But is likely to go wrong badly. AFAIR (according to K&R) p[i] is equivalent to *(p+i), only a different syntax for the same semantics. In contrast to C++ the C language doesn't include arrays as special types, proper usage is up to the coder. > By contrast, an inadvertent duplicate case label is a 'soft' error; the > program just won't give the expected results. It's not going to read or > write all over memory it shouldn't, or at least not as directly as will > happen if the compiler blatantly allows pointers (to single targets) and > arrays to be interchanged. A C switch statement can be translated in various ways, depending on the sparseness of the values and other conditions. A good compiler choses the most efficient model for every single statement. At least the linker should bark on duplicate compiler-generated labels. Some more thoughts: I'd think that everybody in this thread should specify the C standard he relies on. There is a broad range from K&R to C99, or whatever is the current Ansi standard. But I guess none of the contributors ever spent the money and time to read a standard, where many "undefined" and "compiler specific" cases are described in detail. It's a bad idea to rely on the (mis)behaviour of some specific compiler, in a discussion about the semantics of the C language. In former times it was common practice to use multiple C compilers, one for good diagnostics, one for good debugging features, and one for most efficient executable code. At that time the Watcom compiler was said to be the most reliable compiler, dunno about todays version (Open Watcom). The old Microsoft compilers were poor in diagnostics and efficiency, every official sample program contained more than 50 bugs and flaws, which were found by the Borland (BC...) compiler after removing excess (almost wrong) type casts. But it's not the compiler to blame, instead it's the coder that disallows the compiler to perform essential checks, and disables or ignores compiler warnings. It's bad practice to force the compiler to accept some code, with the poor excuse "else it doesn't do what I want". Who wants better diagnostics should consider to use C++ instead of C, and make use of the improved syntax to let the compiler perform more checks. Even newer MS compilers tend to follow their own language definition, not any Ansi standard. Other compilers, like gcc, allow to specify the standard to apply, eventually to enable/disable compiler specific extensions of the language. Any statement about compiler specific behaviour is meaningless without the specification of the compiler and option settings. DoDi