Ok, so first up is question 1.
1.1) typeid(*a); is well formed. It will return the typeid of SubBase2.
1.2) dynamic_cast(a); is well formed as well, as a is of type Base* and SubBase2 is derived from Base. Results in a SubBase2*.
1.3) typeid(*b); is malformed and results in undefined behavior. Since we are in the constructor of SubBase2, type SubBase1 is not a base of SubType2.
1.4) dynamic_cast(b); is malformed and results in undefined behavior. Since we are in the constructor of SubBase2, type SubBase1 is not a base of SubType2
1.5) a->Arr(); Well formed, calls SubBase2::Arr().
1.6) b->Arr(); Malformed, undefined behavior. SubBase1 is not a base of SubBase2.

This example was almost an exact copy of two similar examples from the standard, in section 12.7. When typeid or dynamic_cast is used in a constructor or in a destructor, or in a function called from either, and if the operator of typeid/dynamic_cast refers to the object under construction or destruction, and the static type of the operand is neither the constructor nor the destructors class, nor one of its bases, then the behavior is undefined.

Question 2:
2.1) X* p; Is well formed, pointers to incomplete types are allowed.
2.2) X a; Is malformed, this results in infinite recursion and hence the result is undefined behavior.

This one was an exact copy of the standard, from section: 14.7.1 -14.

1. Does the first numbered line result in defined behavior?

Yes

2. What should the first numbered line do?

It should reuse the storage occupied by *this.

3. Is the behavior of the second and third numbered lines well defined?

Yes and no – the third line potentially writes to unallocated memory, depending on the size of Derived. If it does not, it is well defined.

4. Is the fourth numbered line valid? If so, why? If not, why?

It is syntactically valid and semantically valid as per 3.8.5. Ignoring any undefined behaviour which resulted from previous lines, that is.

5. Is the fifth numbered line valid? If so, why? If not, why?

It is syntactically valid, but results in undefined behaviour as the lifetime of *p has ended.

2.What is the behavior of calling void exit(int);?

The exit function from cstdlib exits the program without unwinding the stack or completing execution of its current block. It has undefined behaviour if you call the function when destroying an object with static storage duration.

3.1 Does the first numbered line result in defined behavior?

Yes. It is well defined as per 3.7.3.8.

3.2 Is the behavior of the second line defined? If so, why? If not, why is the behavior not defined?

It is not defined as you must ensure that an object of the same type occupies the storage when the implicit call to the objects destructor takes place. This applies to objects with static and automatic storage duration (objects which have an implicit destructor call).

4. What is the behavior of int& p = *(int*)0;? Why does it have that particular behavior? Is this a null reference?

This results in undefined behaviour, as it is derefencing a null pointer.

5. What is the behavior of the numbered line in the following code if I is defined as typedef int I;?

It ends the lifetime of the int object, as per 12.4.15.

Quiz answers:
During the construction of a const object, if the value of the object or any of its sub objects are accessed through an lvalue that is not obtained, either directly or indirectly, from the constructor’s this pointer, the value of the object or sub object thus obtained is unspecified. As such the answers to questions 1, 2 and 3 are:
1. i will contain an unspecified value as obj.c results in an unspecified value.
2. It will print out 1.
3. After the evaluation of the third numbered line, p->c will contain the unspecified value that was in i.
4. The unspecified value in obj.c will be printed.

At most only a single user defined conversion (constructor or conversion function) is implicitly applied to a single value. As such the answers for questions 4 and 5 are:
5. This should result in a compile time error.
6. The type is explicitly converted to type X using a conversion constructor, and operator int() will be called on that X type, resulting in the int containing the integral value returned by X::operator int()

An explicit constructor constructs objects only where the direct-initialization syntax or casts are explicitly used. As such the answer for question 6 is:
7. The first numbered line will result in an error, the second numbered line will result in z2 being assigned the value in an unnamed temporary constructed during the static cast.

A typedef-name that names a class shall not be used as the identifier in the declarator for a destructor declaration. As such the answer to question 7 is:
8. The results of the calls on the numbered lines, irrespective of the other lines are.
a. Calls Base::~Base()
b. Calls Derived::~Derived()
c. Calls Derived::~Derived()
d. Calls Base::~Base()
e. This line should result in an error as this is clearly a decleration of a destructor (used in a function call syntax). As such the usage of the typedef is illegal. However it has been noted that many compilers will accept this syntax as legal. That does not mean that you should do it, nor expect it to work correctly.

1.1 – No, it is undefined behavior as the only allowable range for pointers derived from p is [p, p + 10].

1.2 – Since the behavior is undefined, this is meaningless

1.3 – Comparison between other pointers derived from p. Decrement and subtraction by any value that would keep k within [p, p + 10]. Subtraction between k and any other pointer derived from p to obtain a ptrdiff_t.

2. Undefined behavior. Due to a being a scalar type, and the lack of sequence points present, along with the fact that function parameters are evaluated in an unspecified order (but are guaranteed to be evaluated prior to the function call), a will be modified more than once between sequence points. This results in undefined behavior per the standard.

3. the , operator will evaluate its arguments from left to right, returning the result of the rightmost expression. As such the parameters passed to f are: c, d, e, and i.

4. There is a potential for the first or second new to be called, and then the alternate new to throw an exception, causing a leak. Also, there may be construction order dependencies between A and B, and due to the implementation defined order in which function parameters are evaluated, that dependency could be violated. There is the potential for leakage from f, although that’s a non-issue since we appear to be transferring ownership of the pointer to f.