Code with undefined behavior in C#

In C++ there are a lot of ways that you can write code that开发者_如何学Python compiles, but yields undefined behavior (Wikipedia). Is there something similar in C#? Can we write code in C# that compiles, but has undefined behavior?

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 division int.MinValue/-1 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:

https://learn.microsoft.com/en-us/archive/blogs/ericlippert/odious-ambiguous-overloads-part-two

However, the situations in which a safe, well-behaved C# program has implementation-defined behaviour should be quite rare.

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 of false.

CLI believes that false is a byte containing 0, and all other values are true.

This discrepancy means we can coerce C# to do some a (marginally) interesting things thing:

//non-standard bool
//We're setting a bool's value to a byte value of 5.
var a = new bool[1];
Buffer.SetByte(a, 0, 5);

//non-standard bool
//We're setting a bool's value to a byte value of 10.
var b = new bool[1];
Buffer.SetByte(b, 0, 10);

//Both are true.
Console.WriteLine(a[0]);
Console.WriteLine(b[0]);

//But they are not the same true.
Console.WriteLine(a[0] == b[0]);

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):

I.E. the language will stay entirely unconcerned about nonstandard bools. The particular implementation (as in MS C# on CIL) will acknowledge the existence of nonstandard bools and specify their behavior as undefined

Looking at the Wikipedia article on undefined behaviour, 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#

According to the ECMA-334 document (p. 473):

A program that does not contain any occurrences of the unsafe modifier cannot exhibit any undefined behavior.

That promotes 'implementation-defined' to the worst case, see Eric Lippert's answer.

Many and subprograms have requirements that can be summarized as:

1. When given valid data, produce valid output.

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

Not really in the exactly Wiki sense but I suppose the most obvious example that comes to my mind is simply writing some threaded code, but then it's like that in any language.

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.