Doc. No.: N1283

Date:                    2008-02-18

Authors:              Arjun Bijanki

Reply To:             Arjun Bijanki <arjun.bijanki@microsoft.com>

Subject:               Proposal to add _Unaligned to C1x.

This paper proposes the edits necessary to add the keyword _Unaligned and associated semantics to the C1x standard.

Summary

The C language requires that objects be allocated storage that supports their alignment requirement (3.2/1).  _Unaligned does not change this; it simply allows the programmer to safely access objects whose storage does not fulfill the object’s alignment requirements.  For example, some object serialization formats may persist objects in an unaligned state.

_Unaligned is presented as a type qualifier, and causes the accesses of the qualified object to be unaligned accesses.  An unaligned access is an implementation-defined way of guaranteeing that the data access does not generate an alignment fault.  There are not necessarily observable side-effects to an unaligned access other than the absence of an alignment fault.

In general, accessing unaligned data will be slower than accessing regularly aligned data.

Examples:

1) int _Unaligned x;  /* Legal; accesses to x are unaligned. */

2) int _Unaligned* y;  /* Legal; accesses through y are unaligned, but accesses of y are normal. */

3) int * _Unaligned z;  /* Legal; accesses of z are unaligned; accesses through z are normal. */

4) typedef struct _X { int _Unaligned i; } X;

void f(X *x1) {

     x1->i++;   /* Legal; access of i is unaligned. */

     (*x1).i++; /* Legal; access of i is unaligned. */

}

5)

void f()
{

int _Unaligned i;     /* Illegal; cannot be used on locals. */
}

6) typedef struct _X { int i; } X;

void f(X _Unaligned* x)
{

     x->i++;    /* Legal; access of i is unaligned. */
}

Details

Below are the proposed modifications to N1256.

6.2.5 Types

26        Any type so far mentioned is an unqualified type. Each unqualified type has several

qualified versions of its type,38) corresponding to the combinations of one or more of the const, volatile, restrict, and _Unaligned qualifiers. The qualified or unqualified versions of a type are distinct types that belong to the same type category and have the same representation and alignment requirements.39) A derived type is not qualified by the qualifiers (if any) of the type from which it is derived.

6.4.1 Keywords

Syntax

               [add _Unaligned]

6.7.3 Type qualifiers

Syntax

1          type-qualifier:

const

restrict

volatile

_Unaligned

6.7.3 Type qualifiers

Constraints

            Local variables and function parameters shall not be qualified with _Unaligned.

Semantics

Accesses of an _Unaligned object are guaranteed to not cause an alignment fault.  Such accesses are likely to be slower than accesses of an unqualified object, so _Unaligned is intended to only be used where an object’s alignment requirement cannot be guaranteed by the program (for example, see 6.3.2.3/7).

6.3.2.3 Pointers

7          A pointer to an object or incomplete type may be converted to a pointer to a different

object or incomplete type. If the resulting pointer is not correctly aligned57) for the

pointed-to type, and the pointed-to type is not qualified with _Unaligned, the behavior is undefined. Otherwise, when converted back again, the result shall compare equal to the original pointer. When a pointer to an object is converted to a pointer to a character type, the result points to the lowest addressed byte of the object. Successive increments of the result, up to the size of the object, yield pointers to the remaining bytes of the object.