==========================================================

Submitter: Kayvan Memarian and Peter Sewell

Submission Date: 2016-09-22

Document: WG14 N2091

Related: Section 1 of N2012, Question 2/15 of our survey Section 3.1 (Q47-48) of our N2013, and DR338.

1 Summary

This document is based on N2012 (Section 1), adding a concrete Technical Corrigendum proposal for discussion and revising the text.

1.1 Problem

In ISO C11 (following C99) trap representations are particular object representations that do not represent values of the object type, for which merely reading a trap representation (except by an lvalue of character type), is undefined behaviour. See 3.19.4, 6.2.6.1p5, 6.2.6.2p2, DR338. An "indeterminate value" is either a trap representation or an unspecified value.

Trap representations complicate the language and they create the possibility for subtle bugs, e.g. if a programmer inadvertently constructs a trap representation and the resulting (unbounded) undefined behaviour is exploited by some unexpected compiler optimisation. It is not clear how they are significant they are in practice for current C implementations:

1.2 Outline of proposal

In an ideal world we'd remove trap representations from the standard, following (a) for the first two bullets above; we'd then also be able to remove the concept of "indeterminate value", leaving just "unspecified value".

If that is not feasible, e.g. because of the segmented-architecture pointer case, we suggest making the sets of trap representation values for each type be implementation-defined, thereby requiring implementations to document which representations are trap representations - and hence, in the common case that there are none, to document that. That will simplify the task of reasoning about C programs in that case, removing the uncertainty about whether an implementation might be treating some representation values as trap representations.

2 Proposed Technical Corrigendum

2.1 Making Trap Representations implementation-defined

5 Certain object representations need not represent a value of the object type. If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undefined. If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined.50) Such a representation is called a trap representation.

to read

5 Certain object representations need not represent a value of the object type. If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undefined. If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined.50) Such a representation is called a trap representation. The set of trap representations for each object type is an implementation-defined set.

2.2 Option (a) for _Bool

To replace the use of trap representations for non {0,1} _Bool values by unspecified values for the result of operations on such values, one could make a change as below. Such values are converted (by the integer promotion rules) to other integer types before they are operated on, so the unspecified value can be introduced just at the conversion point (and then propagated as in n2089 by the operations).

Extend 6.3.1.2 Boolean type from

1 When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1.59)

to:

1 When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1.59) When a value of _Bool type is converted to any other scalar type, if the value is not 0 or 1 the result is an unspecified value.