Best/worst examples of undefined behavior in C or C++?

Question

Possible Duplicates:
What’s the worst example of undefined behaviour actually possible?
What are all the common undefined behaviour that c++ programmer should know about?
What are the common undefined behaviours that Java Programmers should know about

There are lots of parts of the C and C++ standards that are not completely specified, because to do so might exclude some oddball architecture. Relying on the behavior of your particular compiler and CPU is generally frowned upon, for good reason. On the other hand some behaviors are so universal that you could easily get away with relying on them, even if it is technically undefined.

For example, initializing a pointer to 0xDEADBEEF could lead to bad results on a processor that traps on invalid pointer addresses. But I've never used such a processor, and I'll bet that you haven't either. I'm sure plenty of people have caught a bug or two with this technique, without any winged monkeys taking flight from their nostrils.

On the other hand, if you had old Mac code that depended on the endianness of the processor, you probably lived to regret that decision.

I'd love to see some real world examples of both good and bad reliance on unspecified behavior. It will be interesting to see which type gets the most votes.

There was a similar question with an entirely different emphasis: What’s the worst example of undefined behaviour actually possible?. I'm asking for examples where you are relying on the undefined behavior.

Answer 1

Identical char literals might point to the same memory and might be editable, if an edit changes one, both or isn't allowed is undefined

Answer 2

This is type of thing is reasonably common:

void free_and_null(void **p)
{
    free(*p);
    *p = NULL;
}

int *x = malloc(100);
free_and_null((void **)&x);

...and it can, at least in theory, break these days on compilers that optimise assuming strict interpretation of aliasing rules.

The absolute most common one is probably the old trick of retrieving the value of a union member that wasn't the one most recently stored to.

Answer 3

How many times have I seen code like this:

void write(int fileID,int data)
{
    write(fileID,&data,4); // If they are on the ball 4 is sizeof(int)
}

int read(int fileID)
{
    int result;
    read(fileID,&result,4);
}

But no consideration to endianess.

Answer 4

I think that as a paradigm, thinking too much in terms of undefined and defined is a bad idea.

I see a lot of braindead C++ lawyering on here, and I think it causes a lot of the really bad thinking which causes a lot of the really bad programming that seems to be the norm.

Of course I'm not suggesting to do stuff that has no guaranteed result, but usually the train to undefined land has a first stop when you try to use all of the crazy features that rules lawyering will lead you to in the first place. Like using const improperly (almost all uses of it), complicated initializers in the constructor, exceptions (due to the implementation), etc.

You need to understand more the why than the what of everything or you are just doomed. Especially when the rules of C++ change all the time, generally making them much more complicated and buggy. I see all the time someone posts some mindbogglingly stupid answer because all they seem to know is the C++ rules, not how compilers have to work or how languages generally handle things or why things are the way they are.

Answer 5

There is the static initialization order problem. When specifying two static variables in different .cpp's, and one is initialized using the other, the initialization order is undefined. In my opinion, this renders the static data almost useless.

The workaround is to wrap the static value in a function, as follows:

Value value()
{
    static Value ret(otherStaticInstance);
    return ret;    
}

Answer 6

When defining two functions with the same name in the .cpp only (in separate .cpp's), the compiler won't complain, but pick one of both implementations randomly. The workaround is to wrap the function in an unnamed namespace.

Answer 7

Overflow on signed integers is undefined.

But the following code, assuming both a and b are positive, just works everywhere :)

int a, b;
    /* maximize some value */
    if (a + b < a) { /* oops */ }
    else { maxval = a + b; }

The proper way is to test for overflow before causing the Undefined Behaviour

int a, b;
    /* maximize some value */
    if (a > INT_MAX - b) { /* oops */ }
    else { maxval = a + b; }