Re: diagnosing C errors, was Alternative C compilers on x86_64 Linux?

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

Return to the comp.compilers page.
Search the comp.compilers archives again.