Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #1763
| From | Hans-Peter Diettrich <DrDiettrich1@netscape.net> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: diagnosing C errors, was Alternative C compilers on x86_64 Linux? |
| Date | 2016-09-10 00:38 +0200 |
| Organization | Compilers Central |
| Message-ID | <16-09-024@comp.compilers> (permalink) |
| References | <16-09-001@comp.compilers> <16-09-002@comp.compilers> <16-09-008@comp.compilers> <16-09-019@comp.compilers> |
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
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Alternative C compilers on x86_64 Linux? arnold@skeeve.com (Aharon Robbins) - 2016-09-02 03:01 +0000
Re: Alternative C compilers on x86_64 Linux? jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-05 00:20 +0200
Re: Alternative C compilers on x86_64 Linux? alexfrunews@gmail.com - 2016-09-05 17:26 -0700
Re: diagnosing C errors, was Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-09-09 12:31 +0100
Re: diagnosing C errors, was Alternative C compilers on x86_64 Linux? Kaz Kylheku <221-501-9011@kylheku.com> - 2016-09-09 16:06 +0000
Re: diagnosing C errors, was Alternative C compilers on x86_64 Linux? Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2016-09-10 00:38 +0200
Re: Alternative C compilers on x86_64 Linux? Nemo <nemo@invalid.invalid> - 2016-09-04 18:32 -0400
Re: Alternative C compilers on x86_64 Linux? Kaz Kylheku <221-501-9011@kylheku.com> - 2016-09-04 23:48 +0000
Re: Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-09-05 13:19 +0100
Re: Alternative C compilers on x86_64 Linux? Kaz Kylheku <221-501-9011@kylheku.com> - 2016-09-06 02:15 +0000
Re: Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-09-06 21:35 +0100
Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux? George Neuner <gneuner2@comcast.net> - 2016-09-08 11:58 -0400
Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux? Kaz Kylheku <221-501-9011@kylheku.com> - 2016-09-08 22:54 +0000
Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux? George Neuner <gneuner2@comcast.net> - 2016-09-09 00:51 -0400
Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux? Kaz Kylheku <221-501-9011@kylheku.com> - 2016-09-09 06:05 +0000
Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux? George Neuner <gneuner2@comcast.net> - 2016-09-09 14:02 -0400
Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux? Kaz Kylheku <221-501-9011@kylheku.com> - 2016-09-09 19:57 +0000
Re: duplicate cases, was Alternative C compilers on x86_64 Linux? Andy Walker <anw@cuboid.co.uk> - 2016-09-07 17:01 +0100
Re: Alternative C compilers on x86_64 Linux? Florian Weimer <fw@deneb.enyo.de> - 2016-09-05 20:06 +0200
Re: Alternative C compilers on x86_64 Linux? alexfrunews@gmail.com - 2016-09-05 17:22 -0700
Re: Alternative C compilers on x86_64 Linux? Kaz Kylheku <221-501-9011@kylheku.com> - 2016-09-06 02:18 +0000
Re: Alternative C compilers on x86_64 Linux? rockbrentwood@gmail.com - 2016-09-07 17:00 -0700
Re: Alternative C compilers on x86_64 Linux? arnold@skeeve.com (Aharon Robbins) - 2016-09-12 18:42 +0000
Re: Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-09-12 22:37 +0100
Re: Alternative C compilers on x86_64 Linux? arnold@skeeve.com (Aharon Robbins) - 2016-09-13 17:35 +0000
Re: Alternative C compilers on x86_64 Linux? arnold@skeeve.com (Aharon Robbins) - 2016-09-14 18:14 +0000
Re: Alternative C compilers on x86_64 Linux? rugxulo@gmail.com - 2016-09-26 15:29 -0700
Re: Alternative C compilers on x86_64 Linux? arnold@skeeve.com (Aharon Robbins) - 2016-09-27 05:40 +0000
Re: Alternative C compilers on x86_64 Linux? rugxulo@gmail.com - 2016-09-27 16:36 -0700
Re: Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-09-28 18:16 +0100
Re: Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-09-29 14:03 +0100
Re: Alternative C compilers on x86_64 Linux? George Neuner <gneuner2@comcast.net> - 2016-09-29 22:57 -0400
Re: Alternative C compilers on x86_64 Linux? Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2016-09-30 05:03 +0200
Re: Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-09-30 12:00 +0100
Re: Alternative C compilers on x86_64 Linux? Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2016-09-30 20:15 +0200
Re: Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-10-01 22:17 +0100
Re: Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-09-30 12:28 +0100
Re: Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-10-17 22:49 +0100
Re: Alternative C compilers on x86_64 Linux? George Neuner <gneuner2@comcast.net> - 2016-09-28 21:24 -0400
Re: Alternative C compilers on x86_64 Linux? George Neuner <gneuner2@comcast.net> - 2016-09-28 01:01 -0400
Re: Alternative C compilers on x86_64 Linux? arnold@skeeve.com (Aharon Robbins) - 2016-09-29 02:55 +0000
Re: Alternative C compilers on x86_64 Linux? arnold@skeeve.com - 2016-09-29 05:30 -0600
Re: Alternative C compilers on x86_64 Linux? arnold@skeeve.com (Aharon Robbins) - 2016-09-30 10:13 +0000
csiph-web