+- 0Day Forums (https://0day.red)
+-- Forum: Coding (https://0day.red/Forum-Coding)
+--- Forum: C# (https://0day.red/Forum-C)
+--- Thread: What are the common undefined/unspecified behavior for C that you run into? (/Thread-What-are-the-common-undefined-unspecified-behavior-for-C-that-you-run-into)
What are the common undefined/unspecified behavior for C that you run into? - maureenltvqh - 07-24-2023
An example of unspecified behavior in the C language is the order of evaluation of arguments to a function. It might be left to right or right to left, you just don't know. This would affect how `foo(c++, c)` or `foo(++c, c)` gets evaluated.
What other unspecified behavior is there that can surprise the unaware programmer?
RE: What are the common undefined/unspecified behavior for C that you run into? - thakorwn - 07-24-2023
Be sure to always initialize your variables before you use them! When I had just started with C, that caused me a number of headaches.
RE: What are the common undefined/unspecified behavior for C that you run into? - arunfheotkpywu - 07-24-2023
My favorite is this:
// what does this do?
x = x++;
To answer some comments, it is undefined behaviour according to the standard. Seeing this, the compiler is allowed to do anything up to and including format your hard drive.
See for example [this comment here][1]. The point is not that you can see there is a possible reasonable expectation of some behaviour. Because of the C++ standard and the way the sequence points are defined, this line of code is actually undefined behaviour.
For example, if we had `x = 1` before the line above, then what would the valid result be afterwards? Someone commented that it should be
> x is incremented by 1
so we should see x == 2 afterwards. However this is not actually true, you will find some compilers that have x == 1 afterwards, or maybe even x == 3. You would have to look closely at the generated assembly to see why this might be, but the differences are due to the underlying problem. Essentially, I think this is because the compiler is allowed to evaluate the two assignments statements in any order it likes, so it could do the `x++` first, or the `x =` first.
[1]:
[To see links please register here]
RE: What are the common undefined/unspecified behavior for C that you run into? - Promadysonzobzzlrp - 07-24-2023
A compiler doesn't have to tell you that you're calling a function with the wrong number of parameters/wrong parameter types if the function prototype isn't available.
RE: What are the common undefined/unspecified behavior for C that you run into? - somnambulation237 - 07-24-2023
The EE's here just discovered that a>>-2 is a bit fraught.
I nodded and told them it was not natural.
RE: What are the common undefined/unspecified behavior for C that you run into? - ransdell433 - 07-24-2023
Another issue I encountered (which is defined, but definitely unexpected).
char is evil.
* signed or unsigned depending on what the compiler feels
* **not** mandated as 8 bits