Create an account

Very important

  • To access the important data of the forums, you must be active in each forum and especially in the leaks and database leaks section, send data and after sending the data and activity, data and important content will be opened and visible for you.
  • You will only see chat messages from people who are at or below your level.
  • More than 500,000 database leaks and millions of account leaks are waiting for you, so access and view with more activity.
  • Many important data are inactive and inaccessible for you, so open them with activity. (This will be done automatically)


Thread Rating:
  • 194 Vote(s) - 3.7 Average
  • 1
  • 2
  • 3
  • 4
  • 5
What are the common undefined/unspecified behavior for C that you run into?

#1
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?
Reply

#2
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.
Reply

#3
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]

Reply

#4
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.
Reply

#5
The EE's here just discovered that a>>-2 is a bit fraught.

I nodded and told them it was not natural.

Reply

#6
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
Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)

©0Day  2016 - 2023 | All Rights Reserved.  Made with    for the community. Connected through