The correct answer would be “I don’t know”, because how much memory the compiler allocates for an object is an important opimisation question. In fact, on my system, the compiler refuses to allocate anything less than 64 bits. However, for the picky, there are several ways to control the specific size and layout used for records, depending on what our requirements are:

• The Bit_Order attribute allows control over the endianness of objects,
• The Alignment attribute allows control over the alignment of objects,
• The Size attribute allows control over allocated space for an object,
• The Component_Size attribute allows control over allocated space for each element in an array, and
• A record representation clause let’s us specify down to the bit level exactly how the compiler should lay out a record.

The most important out of the way first: the addition operator in A+B is only defined when A and B are of the same type. Since A and B are different types in this case, we will get a compilation error.

When defined, the result of addition will be of the same type as the operands – unless the result does not fit into the range of that type, in which case a Constraint_Error exception will be thrown.1¹ In other words, simple signed addition does not cause undefined behaviour in Ada.

The type system shows through in a couple of other places in this code, though:

1. It is illegal to assign 0 to a variable of type Character. Why? Because Character is an enumeration type covering the 256 codepoints in the first row of unicode basic multilingual plane – it is not a numeric type.
2. The result of the comparison operator = is of boolean type, and Ada will not let us pretend it’s an integer.

Oh, and we also can’t get the Size attribute of an intermediary value – this is mostly just because that’s left out of the syntax. To get the size, we have to have a variable storing the object. That variable will have to have a type explicitly specified, which avoids the unknowns in implicit type conversion too.

So, yes, this is very much a compilation error.

You probably see the theme already: this is yet another big, honking compilation error because we can’t multiply things of different types.

If we actually want the multiplication, we can get the numeric value of space as Character'Pos(' '), but then of course we can’t store the result in a variable of character type. 2² There is also a slightly imaginative alternative interpretation of the intended meaning of the program: the standard library Ada.Strings.Fixed overloads the multiplication operator such that we can do ' ' * 13 and get the string "             ". But that is a string and thus cannot be stored in a Character type variable.

I should lead this by saying that in the original C code, it is not specified whether the author intended for the right shifts to be arithmetic or logical. It doesn’t matter, because we can’t know what the code will produce anyway, but it’s an important distinction that is explicit in the Ada code above.

In principle, this should yield 32 32, because we’re shifting by a certain amount, and then shifting back by the same amount. However, bit shifting is not considered a numeric operation in Ada, so we shouldn’t expect infinite precision. Bit shifts are thought of as low-level operations needed primarily to interface with hardware or other languages. That’s why we had to import it from the Interfaces standard library.

So the question is: what does Ada 2012 deal with overshifting?

I don’t know. Is it unknowable? I also don’t know.

I have found references to people who should know what they are doing who work under the assumption that overshifting is specified as silently dropping the excess significant bits. I think this is indeed what happens in most (all?) implementations, but the standard does not mention it. The compiler documentation is just as silent.

What I do know is this: shifting is considered an Intrinsic. This means that no implementation is provided in the library, because the compiler is responsible for knowing how to generate efficient code for those functions. This could be interpreted as shifts being implementation defined. I think the defined part of “implementation defined” means that at worst, an implementation must define it to throw an exception at run time. Crucially, that interpretation means it cannot result in erroneous execution, which is the Ada equivalent of C’s infamous undefined behaviour, and what we desperately want to avoid.

If so, I could chalk it up to sloppy documentation writing for the compiler, but I’m still not quite satisfied. At some point in the future, when I have more time to spare, I’d have to follow up on it.

In all cases, this is a compilation error. However, the exact error message will differ a little depending on which version of Ada we use.

Ada 2005 is the less interesting one, because in all Ada versions prior to 2012, functions were not allowed to have parameters marked out, so the Increment function triggers a compilation error. This restriction was put in place exactly to prevent problems like this.

This means that if we want to call a subprogram that modifies variables in the environment it’s called, we’ll have to call it as a separate statement, and we can’t embed it in an expression where data dependencies are uncertain. Restricting functions like this is a pretty blunt tool, but if safety and reliability are important to us, we might consider this worth the little flexibility we lose.

In Ada 2012, the restriction on out parameters in functions was lifted, and functions are allowed to modify variables in their environment. This is possible because in Ada 2012, it is instead specified on a more fine-grained level in which cases functions with out parameters are allowed. If the compiler detects an expression where the same object is supplied to an out mode parameter more than once, it will end compilation saying something along the lines of “conflict of writable function parameter in construct with arbitrary order of evaluation.”