C# Compiler is not consistent with the CLR for the underlying representation of bool

[tannergooding]

Issue

Today the C# compiler does not emit code handling for bool that is consistent with the underlying representation of bool in the CLR.

The C# specification states:

The bool type represents boolean logical quantities. The possible values of type bool are true and false.

The spec also indicates that it is 1-byte. Specifically that the result of the sizeof(bool) expression is 1.

While the ECMA 335 specification states:

A CLI Boolean type occupies 1 byte in memory. A bit pattern of all zeroes denotes a value of
false. A bit pattern with any one or more bits set (analogous to a non-zero integer) denotes a
value of true. For the purpose of stack operations boolean values are treated as unsigned 1-byte
integers (§III.1.1.1).

This can lead to confusion about the handling and cause various inconsistencies in various edge cases (see dotnet/coreclr#16138 (comment), for such a thread).

Proposal

It would be good to determine:

• Should the spec be updated?
  • The spec would explicitly list the expected values of true/false so that two implementations don't behave differently
• Can the compiler be updated?
  • Given that we are emitting for the CLR, we would make our handling match the expected representations for the two boolean values (0/not 0) of the underlying platform

Current Behavior

The majority of the behaviors below actually match the CLR expectation that a bool can be more than just 0 or 1. However some of the behaviors (such as &&) does not match this expectation and can cause issues when interoping with any code that would assume otherwise (generally this is some kind of interop or unsafe code).

• !value

ldarg.1
ldc.i4.0
ceq

• left == right

ldarg.1
ldarg.2
ceq

• left != right

ldarg.1
ldarg.2
ceq
ldc.i4.0
ceq

• left & right

ldarg.1
ldarg.2
and

• left | right

ldarg.1
ldarg.2
or

• left ^ right

ldarg.1
ldarg.2
xor

• left && right

ldarg.1
ldarg.2
and

• left || right

ldarg.1
ldarg.2
or

• value ? "true" : "false"

ldarg.1
brtrue.s

[tannergooding]

Talked with @MadsTorgersen briefly and it was determined logging an issue for this would be good.

There is the normal concern of this being a breaking change, since any change to the handling of the bools will cause code reliant on that behavior to go down a different code path (this, at the very least, impacts the && code pattern, which treats any number with the first bit set as true, and any other value as false).

Also FYI. @jaredpar, @mikedn, @jkotas

[gafter]

The C# language specification is not specific to any particular runtime platform. The only observable consequence of placing something like that in the specification would be the behavior you get when you overlay a bool and a byte in unsafe code. Specifying that would be a peculiar departure from the normal situation in which the specification avoids telling you in detail the way unsafe code works.

[tannergooding]

The only observable consequence of placing something like that in the specification would be the behavior you get when you overlay a bool and a byte in unsafe code.

Only if you limited such code to C#.

It is entirely possible for C# to be consuming code produced by another language where the bool value conforms to the CLR definition but doesn't line up with the C# implementation. In which case updating the spec would cause the behavior in that scenario to be well-defined instead of undefined or implementation-specific.

[gafter]

See also #12211 #14262 and https://web.archive.org/web/20160318193105/https://roslyn.codeplex.com/workitem/224

@tannergooding What languages do you have in mind that use a different representation for bool?

[tannergooding]

ILASM, in general. C++/CLI for desktop, although it could realistically be any language compiled to IL (such as C or C++). There are several programs for converting between LLVM bytecode and IL bytecode, for example. extern methods are not unsafe and can also return a bool value that is not 0 or 1.

As a hypothetical example:

.method public hidebysig static 
        bool MyTrue () cil managed 
{
    .maxstack 8

    IL_0000: ldc.i4.2
    IL_0001: ret
}

The C# language would see this as static bool MyTrue() and the value returned would be true, according to the ECMA-335 spec (Common Language Infrastructure specification). However, C# would handle it incorrectly for the case of &&.

[gafter]

See the last entry in https://web.archive.org/web/20160318193105/https://roslyn.codeplex.com/workitem/224 for how we resolved this in 2014. The resolution was that we would document it (presumably, in https://github.com/dotnet/roslyn/tree/master/docs/compilers) but we do not appear to have done so.

[tannergooding]

I don't believe the linked resolution is exactly correct.

The last comment is making a statement that the runtime bools have more than two states. However, it could easily be argued that they do in fact only have two states (true, which is a bit pattern with any one or more bits set; or false, which is a bit pattern of all zeros).

For the runtime, a boolean with a bit pattern of 10 is equivalent to a bit pattern of 01, they represent the same state.

[tannergooding]

I'm also not sure it will be clear what a "non-standard" bool is without clearly defining the underlying bit representation of true and false. Otherwise, the exact definition of a "standard" bool is still dependent on the underlying runtime and the implementation of a given C# compiler.

For example, the current Roslyn implementation is generally inline with the runtime definition, except for a couple of weird scenarios with the short-circuit comparisons where it treats it as true has a bit representation with the least significant big set and false has a representation with the least significant bit cleared.

[HaloFour]

So wouldn't this also mean that any C# assembly exposing a bool wouldn't be CLS compliant because of violations of the ECMA spec?

The argument that C# is independent of the CLR is a copout. C# exists in an ecosystem with other languages bound by the common contract that is the CLS/CLR. More than once has the argument been made against various C# proposals given that they would not play well across that ecosystem. It's ludicrous to expect that every other compiler that might want to target the CLR will have to know about this backwards behavior in order for it to produce assemblies that will work as expected.