In C++ there are a lot of ways that you can write code that compiles, but yields undefined behavior (Wikipedia). Is there something similar in C#? Can we write code in C# that compiles, but has undefined behavior?
相关问题
- Sorting 3 numbers without branching [closed]
- Sorting 3 numbers without branching [closed]
- Graphics.DrawImage() - Throws out of memory except
- Why am I getting UnauthorizedAccessException on th
- How to compile C++ code in GDB?
As others have mentioned, pretty much anything in the "unsafe" block can yield implementation-defined behaviour; abuse of unsafe blocks allows you to change the bytes of code that make up the runtime itself, and therefore all bets are off.
The corner case of integer division has an implementation-defined behaviour.
Throwing an exception and never catching it causes implementation-defined behaviour -- terminate the process, start a debugger, and so on.
There are a number of other situations in C# where we are forced to emit code which has implementation-determined behaviour. For example, this situation:
http://blogs.msdn.com/ericlippert/archive/2006/04/06/odious-ambiguous-overloads-part-two.aspx
However, the situations in which a safe, well-behaved C# program has implementation-defined behaviour should be quite rare.
In general I would say no.
Use Automatic variable before it’s initialized.
All variables must be initialized. If not an exception occurs.
Division by zero
Exception is thrown.
Indexing an array out of bounds
Exception is thrown
As Aequitarum Custos pointed out you can use unsafe code. Then again this isn't really C#, you are explicitly opting out of the C# environment.
Many and subprograms have requirements that can be summarized as:
When given valid data, produce valid output.
Refrain from launching nuclear missiles or negating the laws of time and causality, even when given invalid input.
One of the major design goals of Java and .NET languages is that unless code makes use of certain which are marked as "unsafe", no particular effort is generally required to meet the second constraint above [though some behaviors related to garbage collection and
Finalize
can be a little weird from the time/causality standpoint, those can be described as exceptions to normal rules of causality, rather than a total revocation of them]. That situation is very different from the situation in C, where many kinds of data-dependent errors (e.g. integer overflow) may result in compilers behaving in arbitrary fashion including making whatever assumptions would be necessary to avoid overflow. The truly horrible kinds of Undefined Behavior which are encouraged in hypermodern C philosophy do not exist in C# or other .NET languages outside of "unsafe" blocks.According to the ECMA-334 document (p. 473):
That promotes 'implementation-defined' to the worst case, see Eric Lippert's answer.
Yes! There is, even in a safe context! (Well, it's implementation defined to be undefined, at least)
Here's one from Marek Safar and VSadov in the Roslyn issues.There is a mismatch between C# and the CLI in regards to
bool
.C# believes that there is only one kind of
true
, and one kind offalse
.CLI believes that
false
is a byte containing 0, and all other values aretrue
.This discrepancy means we can coerce C# to do
somea (marginally) interestingthingsthing:The above outputs:
true
true
false
Interestingly, the debugger disagrees (must evaluate truth differently?)
Anyways, the conclusion the C# team appears to have come to is (emphasis added):
Looking at the Wiki, the situations in which undefined behavior happens are either not allowed or throw an exception in C#.
However in Unsafe code, undefined behavior I believe is possible, as that allows you to use pointers etc.
Edit: It looks like I'm right: http://msdn.microsoft.com/en-us/library/aa664771%28VS.71%29.aspx
Has an example of undefined behavior in c#