Hacker News Reader

Comment by qiqitori | Hacker News Reader

Does anyone have any examples of undefined behavior in C where it isn't pretty obvious that you'll get undefined behavior?

View on HN

At file scope:

int this_is_a_fairly_long_variable_name_1;

int this_is_a_fairly_long_variable_name_2;

Why? Because section 5.2.4.1 requires implementations to support at least 32 significant characters in external identifiers and section 6.4.2.1 says "If two identifiers differ only in nonsignificant characters, the behavior is undefined."

These ones may be more "obvious", but:

Given e.g. int a[4][5] then accessing a[1][7] is undefined even though one might assume it's like accessing a[2][2]

x << -3 is undefined behaviour though logically one might assume it should be equivalent to x >> 3

And the classic, very common newbie use of "fflush(stdin);" is also undefined.

> x << -3 is undefined behaviour though logically one might assume it should be equivalent to x >> 3

Not saying anything about the other things, but this (in my opinion) is something that should raise eyebrows. At least to me personally that looks rather weird.

Yes, the first two examples in the article weren't obviously enough undefined for the authors of CIL who wrote the list, apparently.

Does the first example contain undefined behaviour? (As written it does because x is not initialised, but the text suggests that a value is actually being provided for x)

I think the second example may contain UB on a <=32-bit architecture (right shift by a value greater or equal to the number of bits), or at least this is UB in C++. On a 64-bit architecture it would be fine (but the result would not be 0).

"The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior"

That isn't obvious?

(It's also not unique to C)

No.

It's not obvious which actions are atomic.

Assume nothing is atomic unless you make it so.

Here's a reply to a comment from a few weeks ago, when someone asked the same thing: https://news.ycombinator.com/item?id=30024805

a[i] = i++ is undefined, even though a[i] = i and a[j] = i++ each do what they obviously should.

> a[i] = i++

And I would never excrete such a line of code without automatically thinking "hmmm.. does this really do what I think it does?"

If I see a[i] = i++ in a codebase I am immediately removing it as it looks ambiguous, possibly invalid and probably unpredictable.

This is just a very particular case of calling a function with such arguments that the result will depend on the order of evaluation for the arguments.

This is an undefined operation in almost all programming languages.

That is not actually the case, a great many languages define the order of operations in a deterministic manner.

There is no intrinsic reason why a[i] = i++ has to result in undefined behavior.

High performance calling conventions depend on machine architecture.

This should be caught by the compiler and reported as an error.

Even if the behaviour is defined, relying on defined non-obvious behaviours means relying on subsequent programmers to have read the spec.

for (i = 0; ; i++)

if i is signed, this is undefined. You'd think it's just a loop though.

It's pretty obvious by looking at that code that it's something weird going on. I don't think anyone would look at it and say "it's ok".

In C, that is usually spelled

    while (1)

It's not that though. While(1) doesn't include a counter that overflows.

The classic way is actually

  for(;;)

Reply on news.ycombinator.com