Re: what is the output of this program?

Eric Sosman <esosman@xxxxxxxxxxxxxxxxxxxx> writes:
user923005 wrote:
Refusing to compile code that exhibits undefined behavior seems more
like a feature than a bug to me.
In fact, I wish that all my compilers would do that. (At least in the
cases where undefined behavior can be repaired).

IMHO that's an unfortunate wish. Here, for example,
is the start of a program that exhibits undefined behavior:

#include <unistd.h>
...

Do you really want the compiler to reject it?

As the Rationale puts it, "the ability to write machine-
specific code is one of the strengths of C." If C were
*unable* to poke I/O registers, *unable* to call dlsym() and
convert a void* to a function pointer, *unable* to overflow
an `int' without trapping, C would be far less useful than
it actually is.

Sure, but there's undefined behavior and then there's undefined
behavior.

There are plenty of constructs whose behavior the standard doesn't
define that can nevertheless be useful in non-portable code.

On the other hand, some constructs, such as ``C == C++'' or
``i = i++'' are, in a sense, more purely undefined, to the extent that
they should never appear in normal C code. Regardless of the
portability of the program, there's always a better way to expression
whatever the intent was.

For such constructs, I certainly have no problem with a compiler
warning about them, or even rejecting the translation unit *if* it can
prove that the code will always be executed.

The tricky (and perhaps undecidable) part is determining which
instances of UB are potentially ok and which are not.

(On the other hand, the way in which the particular compiler
terminated, with an internal assertion failure, indicates a bug in
that compiler -- though the standard doesn't say what a diagnostic has
to look like.)

[...]

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • Re: #define and (brackets)
    ... Minor compiler vendors are free to join if they are so inclined, ... analysis hasn't changed between the two versions of the standard. ... This bug is a minor bug in an obscure ...
    (microsoft.public.vc.language)
  • Re: whats wrong with atof() and casting?
    ... The return type of the function was int, ... Since atofDOES NOT return an int, this is wrong and undefined behavior. ... Note that a compiler is not required to do anything at all when you ... There is no requirement in the C standard that they do. ...
    (comp.lang.c)
  • Re: Code or compiler bug re: TRANSFER intrinsic?
    ... > of the fortran standard. ... compiler I tried had a bug relating to it somewhere. ... the other is what gets associated with the dummy argument. ...
    (comp.lang.fortran)
  • Re: a[i] = x[a[i]]++
    ... is incorrect behavior (not undefined behavior). ... There is nothing in the standard that allows the ... compiler to re-evaluate the location of xfor ... > I checked this with the optimiser both on and off. ...
    (comp.lang.c)
  • Re: [Lit.] Buffer overruns
    ... > to the C standard, ... > compiler warning there is no warning given and thus they ... suitable circumstances, trigger undefined behavior ... I have told you before how to avoid writing code ...
    (sci.crypt)